性能测试基础知识

作者：Gakki

---

基础概念：HPS、TPS、QPS、RPS、RT、并发用户数概念？简要介绍？

HPS（Hits Per Second）：每秒点击次数，单位是次/秒。
TPS（Transaction per Second）：系统每秒处理事务数，简称TPS, 每秒事务数, 是衡量系统性能的一个非常重要的指标。
QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求
RPS 即每秒请求数（Request Per Second），通常用来描述施压引擎实际发出的压力大小。PS：并发数过低时可能达不到预期的 RPS，并发数过高时可能压力过大压垮服务器
并发用户数：简称VU ,指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。
响应时间：简称RT,指的是业务从客户端发起到客户端接受的时间。

压测工具？你主要看哪些指标？

压测工具：jmeter
Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值
# Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间
Median：中位数，也就是 50％ 用户的响应时间
90% Line：90％ 用户的响应时间
Note：关于 50％ 和 90％ 并发用户数的含义
Min：最小响应时间
Max：最大响应时间
Error%：本次测试中出现错误的请求的数量/请求的总数
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数
KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

性能测试中TPS上不去的几种原因浅析？

TPS（Transaction Per Second）：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。

1. 网络带宽。在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2. 连接池。可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
3. 垃圾回收机制。从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4. 数据库配置。高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
5. 通信连接机制。串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
6. 硬件资源。包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7. 压力机。比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8. 压测脚本。还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。
9. 业务逻辑。业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10. 系统架构。比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

性能测试场景设置思路？

无论并发模式还是TPS模式，场景就是一个压测模型，压测模型中有串行的事务（如添加购物车+购物车下单+付款）也有并行的接口（在不同串联链路中的压测API），最终组成一个复杂或者简单的场景。然后根据新业务上线的目标、或者日常峰值的等比例目标、或者重大业务活动的预估支撑能力去设置每个API的目标能力（TPS是一步到位的按照吞吐能力设置的，推荐TPS模式，比如前面提到的添加购物车+购物车下单+付款这种流程就是一个漏斗模型，TPS设置为逐渐变小的模型即可），当然也可以在初期的测试中更谨慎一点，将目标量级设置得整体低一点，当最终能力达到之后建议可以调整原定目标量级到120%或者150%，验证限流准入/高可用基础设施的抗压能力。目标量级即当前压测场景中这个压测API的施压上限。而起步量级可以从5%或者10%开始，过程中视业务指标数据和被压测端的整体负载临时调整。

对服务器性能测试的看法？

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到串联链路（场景）中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。同样的，如果系统间的吞吐能力差别很大，那么同样的并发下TPS差距也会很大。

系统的性能决定的要素？跟并发用户数的关系？

由TPS决定，跟并发用户数没有多大关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。

Jmeter的工作原理是什么？

jmeter可以作为web服务器与浏览器直接的代理网关，以便捕获浏览器的请求和web服务器的响应，如此就可以很容易地生成性能测试脚本。有了性能测试脚本，jmeter就可以通过线程来模拟真实用户对web服务器的访问压力。这与LoadRunner的工作原理基本一致。

你常用的元件、各自的作用是什么？

1. 测试计划(Test Plan)是使用 JMeter 进行测试的起点，它是其它 JMeter 测试元件的容器。
2. 线程组(Thread Group)代表一定数量的并发用户，它可以用来模拟并发用户发送请求。
3. 取样器(sampler)定义实际的请求内容，被线程组包含，我们主要用HTTP请求。
4. 监听器(Listener)
5. 逻辑控制器(Logic Controller)
6. 断言(Assertions)
7. 配置元件(Config Element)
8. 前置处理器(Pre Processors)和后置处理器(Post Processors)
9. 定时器(Timer)

前端的性能应该从哪些方面去测试？应该关注哪些指标？

1. 使用的一些工具
2. 查看静态资源
3. JS、CSS等资源加载速度
4. 页面渲染
5. 不同浏览器上加载速度

什么是缓存？

缓存就是在内存中存储的数据备份，当数据没有发生本质变化的时候，我们避免数据的查询操作直接连接数据库，而是去 内容中读取数据，这样就大大降低了数据库的读写次数，而且从内存中读数据的速度要比从数据库查询要快很多。

什么是Redis？

1）Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2）Redis支持master-slave(主-从)模式应用
3）Redis支持数据持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
4）Redis单个value的最大限制是1GB，memcached只能保存1MB的数据。

什么是全链路压测？

基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程

性能测试关注的指标是什么？

1. 用户数

• ①注册用户数
  注册用户数指软件中已经注册的用户，这些用户是系统的潜在用户，随时都有可能上线。这个指标的意义在于让测试工程师了解系统数据中的数据总量和系统最大可能有多少用户同时在线。
• ②在线用户数
  在线用户数是指某一时刻已经登录系统的用户数量。在线用户数只是统计了登录系统的用户数量，这些用户不一定都对系统进行操作，对服务器产生压力。
• ③并发用户数
  不同于在线用户数，并发用户数是指某一时刻向服务器发送请求的在线用户数，他是衡量服务器并发容量和同步协调能力的重要指标，从这个含义上讲，我们可能会如下两种理解：
  同一时刻向服务器发送相同或者不同请求的用户数，也就是说，既可以包括对某一业务的相同请求，也可以包括对多个业务的不同请求
  同一时刻向服务器发送相同请求的用户数，仅限于某一业务的相同请求

2. 事务的响应时间
   事务是指用户在客户端做一种或多种业务所做的操作集，事务的响应时间就是衡量用户执行这些操作集所花费的时间。在性能测试中，一般通过计算事务的开始时间和结束时间的差值来获取事务的响应时间。
   一个事务表示一个“从用户发送请求->web server接受到请求，进行处理-> web server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。
3. 每秒点击数
   每秒点击数是指每秒钟像web服务器提交的HTTP请求数，它是衡量服务器处理能力的一个常用指标。需要注意的是，这里的相应时间并非鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求，切勿混淆。
4. 吞吐率
   吞吐率通常指单位时间内从服务器返回的字节数，也可以单位时间内客户提交的请求数。吞吐率是大型web系统衡量自身负载能力的一个重要指标，一般来说，吞吐率越大，单位时间内处理的数据就越多，系统的负载能力也强。吞吐率与很多因素有关，服务器的硬件配置，网络的宽带及拓扑结构，软件的技术架构等。
5. 业务成功率
   指多用户对某一业务发起操作的成功率。例如，测试网络订票系统的并发处理性能，在早上8:00——8:30半小时的高峰里，要求能支持10万比订票业务，其中成功率不少于98%。也就是说系统允许200笔订票业务超时或者因其他原因导致未能订票成功。
6. TPS - 吞吐量
   TPS表示服务器每秒处理的事务数，他是衡量系统处理能力的一个非常重要的指标，在性能测试中，通过检测不同用户的TPS,可以估算出系统处理能力的拐点。
7. 资源利用率
   资源利用率就是指资源的使用情况
   CPU使用率70%—80%，内存使用率80%以下
   网络带宽利用率 100Mbps=12.5MB/s
8. QPS - 查询率
   QPS：每秒查询率，因特网上经常用每秒查询率来衡量域名系统服务器的机器的能。
   对应请求数/sec，即每秒的响应请求数，也即是最大吞吐能力。
9. 错误率：一批请求中结果出错的请求所占比例。

如果你要进行性能测试，你是如何展开操作的？

1. 确定关键业务，关键路径
2. 确定输入参数以及输出参数，指定负载测试方案
3. 准备测试环境，完成脚本录制，或者测试脚本开发，
4. 执行测试，观察或输出参数，如（数据吞吐量，响应时间，资源占有率等）
5. 对测试结果进行分析

安全性测试包括哪些方面？

用户验证，用户权限管理，系统数据的保护