压力测试全流程及分析

一、什么是压力测试

   压力测试是通过不断向被测系统施加“压力”，测试系统在压力情况下的性能表现，考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在，也就是我们可以模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。

二、具体操作步骤

1、打开JMeter，新建一个线程组

2、开始新建一个HTTP请求默认值，并配置好web服务器里的信息

3、创建一个HTTP请求，填写好需要压测的接口信息，请求方式、请求路径、以及需要传入的参数是什么

4.创建HTTP消息头管理器，该部分相当于请求头信息，一般需要配置Content-Type：application/json,以及登录后的token

5.之后创建一个响应断言、查看结果树、聚合报告就可以调整并发数进行压力测试了，可以通过聚合报告查看具体的响应数据

三、聚合报告中的数据解释

1、Label：请求的名称，就是脚本中Sampler的名称。

2、#Samples（样本）：总共发给服务器的请求数量，如果模拟10个用户，每个用户迭代10次，那么总的请求数为：10*10 =100次。

3、Average（平均值）：默认情况下是单个Request的平均响应时间，当使用了Transaction Controller（事务控制器） 时，也可以用Transaction的时间，来显示平均响应时间 ，单位是毫秒。

4、Median（中位数）：50%用户的响应时间小于该值。

5、90% Line（90% 百分位）：90%用户的响应时间小于该值。

6、95% Line（95% 百分位）：95%用户的响应时间小于该值。

7、99% Line（99% 百分位）：99%用户的响应时间小于该值。

8、Min（最小值）：最小的响应时间。

9、Maximum（最大值）：最大的响应时间。

10、Error%（异常%）：错误率=错误请求的数量/请求的总数。

11、Throughput（吞吐量）：默认情况下表示每秒完成的请求数（Request per Second）。

12、Received KB/sec （接收数据）：每秒从服务器端接收到的数据量。

13、Sent KB/sec（发送）：每秒发送到服务器端的数据量。

四、压测方法

在压测中我们需要重点关注的数据有 QPS（每秒查询率）= 并发数/平均响应时间、RT（响应时间）、异常率、平均响应时间以及吞吐量，我们可以根据下图去压测找到可能的QPS的最大值

实际举例

我们通过一个实例来把上面几个概念串起来理解。按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。

公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
1、每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

2、如果一台机器的QPS是58，需要几台机器来支持？
139 / 58 = 3

最佳线程数、QPS、RT

   对同一个系统而言，支持的线程数越多，QPS越高。假设一个RT是80ms,则可以很容易的计算出QPS,QPS = 1000/80 = 12.5。多线程场景，如果把服务端的线程数提升到2，那么整个系统的QPS则为 2*（1000/80） = 25, 可见QPS随着线程的增加而线性增长，那QPS上不去就加线程呗，听起来很有道理，公司也说的通，但是往往现实并非如此。

QPS与RT实际关系图如下：

最佳线程数量
刚好消耗完服务器的瓶颈资源的临界线程数，公式如下
最佳线程数量=（（线程等待时间+线程cpu时间）/线程cpu时间）* cpu数量

特性：

在达到最佳线程数的时候，线程数量继续递增，则QPS不变，而响应时间变长，持续递增线程数量，则QPS开始下降。
每个系统都有其最佳线程数量，但是不同状态下，最佳线程数量是会变化的。
瓶颈资源可以是CPU,可以是内存，可以是锁资源，IO资源：超过最佳线程数-导致资源的竞争，超过最佳线程数-响应时间递增。