jmeter 性能测试结果分析_jmeter结果分析

一、性能测试的概念&意义

1、概念

       通过技术的手段模拟大量用户同时访问被测应用，观察、记录和分析系统的各项性能指标的过程。

2、目的

评估系统的性能瓶颈，预测系统的最大用户负载能力

3、意义

      能够有效评估系统的性能指标，用于系统的性能评估 2）能够识别系统的性能瓶颈，协助性能调优 3）能够指导突发流量承载方案的制定 4）能够用于系统运维成本的预算

二、性能指标理解

1、指标分析

（1）响应时间

用户通过客户端向服务端发出请求的时间为：T1

服务端接收到请求，处理该请求的时间为：T2

服务端返回数据给客户端时间为：T3

客户端接收到响应数据，处理数据呈现给用户时间为：T4

（2）响应时间系统视角

系统的响应时间 Ts= T1+T2+T3

该时间没有包括客户端对数据处理并呈现的时间 T4

（3）响应时间用户视角

用户眼中的的响应时间 Tu = T1+T2+T3+T4

用户通过客户端发出请求到客户端展现请求结果，这个时间越短越好

（4）响应时间服务器视角

服务器接收到客户端发送的请求，并给出响应，这个过程所消耗的时间为响应时间，即服务器仅关注 T2

从不同的视角下，衡量响应时间的指标也各不相同。在实际测试过程中，要明确以什么视角验证被测对象的性能。

2、并发

（1）并发用户数

简称 VU ,指的是系统中操作业务的用户。一般称为虚拟用户数。并发用户数跟注册用户数，在线用户数有很大差别。并发用户数一定会对服务器产生压力，而在线用户数只是挂在系统上，对服务器不产生压力

（2）在线用户数

在已有系统中选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数

（3）注册用户数

数据库中存在的用户数。并发用户数可以取系统用户数的 10%，例如在半个小时内，使用系统的用户数为 10 万，那么取 10%(即 1 万) 作为并发用户数

（4）系统并发数

一般指测试工具为了模拟出用户并发压力而启动的线程，比如 jmeter 里面的 Thread。由于 jmeter 中的线程有迭代的概念，所以通过线程迭代数就可以模拟出用户单位时间最大的并发数。

注意不要把系统并发数和并发用户数* 的概念混在一起

3、吞吐量

单位时间内系统处理请求的数量。吞吐量直接体现了软件系统的业务处理能力

（1）衡量方式

Rps 请求数/单位时间

Hps 点击数/单位时间

Tps 通过事物数/单位时间

Qps 查询数/单位时间

（2）TPS 模型

随着压力不断增长，实测系统的资源会不断被消耗，TPS 值会因为这些因素而发生变化，并且符合一定的规律

4、基准测试

原点到 a 之间的系统性能，指以系统预期性能指标为前提，对系统不断增加压力，以验证系统能否达到预期性能

5、负载测试

a 到 b 的系统性能，是指对系统不断地增加压力或一定压力下的持续运行，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等

6、压力测试

b 到 d 之间的系统性能，是指超过安全负载的情况下，对系统不断施加压力，直到系统崩溃，找出系统的瓶颈点和崩溃点。

Tps（每秒处理事务数）

一个事务是指客户端向服务器发送请求然后服务器做出反应的过程

单请求事物：事物由单个接口请求构成。如一次登录，一次查询

多请求事物：事物由多个接口请求构成。如登录 - 查询 - 新增 - 退出。这四步操作构成一个完整的事物

TPS 的决定性因素：事务是要靠虚拟用户完成

1 个用户在 1 秒内完成 1 笔事务，那么 TPS 就是 1

1 个事物响应时间是 1ms,那么 1 个用户在 1 秒内能完成 1000 笔事务。TPS 就是 1000

1 笔业务响应时间是 1s,那么 1 个用户在 1 秒内只能完成 1 笔事务。想达到 1000TPS 就至少需要 1000 个用户

因此可以说 1 个用户能产生 1000TPS， 1000 个用户也可以产生 1000TPS，由响应时间决定

5、Rps 每秒发起的请求数

并发数=rps* 平均响应时间

RPS 用来描述施压引擎实际发出的压力大小

RPS 模式主要是为了站在服务端视角去直接衡量系统的吞吐能力-TPS 而设计的

并发过低时可能达不到预期的 RPS，并发过高时可能压力过大直接压垮服务器

按照被压测端需要达到的 TPS 去设置相应的 RPS，应用场景主要是一些动态的接口 API，比如登陆、提交订单

7、吞吐量行业标准

金融行业：1000TPS~50000TPS，不包括互联网化的活动

保险行业：100TPS~100000TPS，不包括互联网化的活动

制造行业：10TPS~5000TPS

互联网电子商务：10000TPS~1000000TPS

互联网中型网站：1000TPS~50000TPS

互联网小型网站: 500TPS~10000TPS

提问：我有一个功能，需要测试一下最大支持多少用户并发？

此时要计算的是最大用户并发数，强调的是同时操作，也可以理解为同时发起请求，我们可以通过 RPS 定时器或者阶梯加压线程组测试每秒最大的请求数

三、吞吐量模式下的阶梯负载

RPS模式负载：RPS是request persecond，也就是每秒的请求数。我们通过持续不断地增加请求来对服务端施压，测试服务端的处理能力，找到瓶颈。

策略

第一次：并发 200，不限迭代次数，同时在请求下面加 RPS 定时器。目的是在 200 线程下，将 RPS 逐步增加到 1000/S,并持续运行一段时间

start=1 end=200，持续时间是 10。表示我们需要在 10s 内将 RPS（每秒请求数）均匀的从 1 提升到 200。

拐点判断方式

1. 通过 Tps走势图观察拐点。吞吐量会随压力的增大呈抛物线状，抛物线的最高点处，即为当前测试环境下该请求的最大处理能力。吞吐量的拐点往往也就是响应时间的拐点。
2. 通过资源消耗判断拐点。比如测试中 Tps 仍呈上升趋势，但 CPU 资源使用率已高达 90%，就以此时 Tps 值为当前测试环境下该请求的最大处理能力。

注意：rps 是客户端每秒发起的请求，tps 是服务端每秒完成的请求。实际情况中，tps 往往和 rps 不等，因为要考虑到中间的网络和服务处理时间

启动 jmeter，运行一段时间之后我们观察一下监听器的数据图表Tps监听

RPS 在 836/s 的时候开始出现拐点，请求曲线的角度开始收窄

TPS 在 730/s 左右开始出现剧波动，可以认为这是吞吐量的一个拐点

在 1:00 秒的时候，也就是 TPS 达到 730/S 的时候，事物开始出现错误

1：此处可能就是一个性能瓶颈
2：有可能是百度对 ip 的访问量做了限流，防止爬虫
3：有可能是我当前环境的问题，包括带宽，内存，cpu 等等资源的限制，后期都需要考虑进去

 在性能稳定的情况下，可以套用公式去计算出最大并发数:并发数 = RPS * 响应时间
1：稳定状态下，最大 RPS= 836/S。这个值可以理解为最大支持 1 秒内 836个用户同时去访问。
2：稳定情况下，响应时间大约长期保持在 160 ms
3：稳定情况下，峰值系统并发数大约是 836*0.16=134。这个值可以理解为只要启动 134个线程就可以在一秒内满足 836/s 的压力值。或者换个角度，也可以表示最大支持 134个用户在 1s 内不停的访问，一直达到瓶颈点

第二次：100 并发
这一次我们把线程数收紧，只给 100 线程。以此观察线程数降低的情况下，压力会不会变小观察到，请求数依然在 820-830 这个区间变缓

结论

此当前环境下，不论是本机资源，还是百度设置了限流等原因，我们的最大请求数只能维持在 820-830，最大 TPS 维持在 700-750 之间，平均响应时间在160-170ms之间，最大系统并发数在 130 左右。超出这个范围就开始出现波动

四、并发用户模式下的阶梯负载

并发用户负载：

我们在讨论负载测试的时候，会说持续稳定地增加系统的负载。那么什么是持续稳定的增加负载呢？jmeter中，线程数可以看做是虚拟并发用户。那么我们想要稳定的增加负载，就需要持续不断地增加并发数。通过并发数的不断增加来考量各种性能指标的变化，找到拐点。

策略：

配置参数的完整描述为：给定负载并发用户数为500，从0秒开始，每3秒内增加50个并发用户数，3秒时刻完成50个并发用户数的启动后开始平稳运行10秒钟，依次下去，直到500个并发用户数全部都启动完成后，平稳运行100秒，然后每隔5秒减少100个并发用户数直到并发用户数减少为0时，负载测试结束。

结合响应时间，tps，活动线程监听器一起分析，可以看到在1分30秒左右的时候，响应时间突然飙升，用户数达到350个并发，这里可以认为是一个瓶颈点

五、如何快速的确定拐点

1、创建多个线程，每个线程数不同，逐渐递增

2、测试计划中，需要勾选独立运行每个线程组，勾选该选项的意义就是依次并发执行10、50、100、200线程，直到压测结束。

3、执行命令 jmeter -n -t E:\jmeter脚本\压测.jmx -l E:\jmeter脚本\聚合报告.jtl -e -o E:\jmeter脚本\webreport

4、分析测试报告

聚合报告如下，随着并发用户增加，平均响应时间在递增，报错率也在递增，TPS也随着用户数的增加和增加，到了500用户为最高点，1000并发用户反而降低

查看Response Times Over Time图表可以看到响应时间随着并发用户数递增，平均响应时间一直增加，当1000并发时，响应时间增加幅度最大

查看Transactions Per Second，从图表可以看出当并发用户从10递增到500，一直是递增趋势，然后500-1000，开始慢慢降低

查看 Hits Per Second，从图表可以看出当并发用户从10递增到500的时间段，每秒请求数一直是递增趋势，然后500-1000并发，请求数开始不增反降

得出结论，暂时不考虑其他因素，确定拐点就是500并发。

施压策略建议：

在实际的工作中，可能习惯性的高并发的去压，单台机器压测2000并发的也有见到过，这是不可取的。我们是为了找到系统最大处理瓶颈，这个需要一点点的并发往上加的，防止服务器太脆弱直接导致压跪掉是很有必要的。

通过很多性能测试案例，发现不需要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。

在做负载测试的时候，一般都是按照梯度施压的方式去增加虚拟用户数，而不是在没有预估的情况下，一次加几万个用户，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义。