（44）负载测试

负载测试

用stepping thread group线程组 设计了一个负载场景
并发用户数从 0–100， 步长是10线程数

• 判断是否达到 最大可接受并发用户数 区间
  • 1、看tps 是否有连续报错
    • 如果出现连续报错， 最大可接受的并发用户数，就是在报错这个时间点，对应的并发用户数之前
  • 2、平均响应时间
    • 看并发用户数相同的一段时间内的 平均响应时间， 是否超过1.5s
  • 3、服务器资源利用率，不能超过预警值

  ---

• 最大可接受并发用户数 VS 最大并发用户数
  • 可接受的标准： 不要连续报错 + 平均响应时间不超过1.5s + 资源利用率不超过预警
  • 最大并发用户数的标准： 服务器处理完全失败
    • 1、项目停止运行
    • 2、服务器机器宕机
    • 3、网络阻塞
  • 一般情况， 都是拿最大可接受并发用户数来进行测试， 而并不是拿最大并发用户数来进行测试。
  • 做 基准测试、性能测试，都是用的 最大可接受的并发用户数 去做。
  • 基准测试： 在没有做过性能测试时，第一次完整的性能测试结果数据

  ---

• 注册接口 最大可接受并发用户数的区间 （30,40）
  • 缩小步长，为 1
  • 起始值设置为30， 最大值设置为40
  • 再次进行负载测试
  • 得到结果 ： 32个并发用户数时，平均响应时间<1.5s，在33的时候，达到了1.5s，所以，我们说 最大可接受的并发用户数值为 32

  ---

jmeter.bat -n -t vip16\fzcs.jmx -l vip16\jtl\fz-003.jtl

jmeter.bat`：启动JMeter的可执行文件。
    -n`：以非GUI模式运行，即无界面模式。
    -t vip16\fzcs.jmx`：指定要运行的测试计划文件路径和名称为"vip16\fzcs.jmx"。
    -l vip16\jtl\fz-003.jtl`：将结果保存到指定的JTL文件中，路径和名称为"vip16\jtl\fz-003.jtl"。

• CLI模式 运行 负载测试场景
  • cli模式中的聚合报告
  • E:\xingnenggongju\apache-jmeter-5.1.1\bin>jmeter.bat -n -t vip16\fzcs.jmx -l vip16\jtl\fz-003.jtl
  • 这是一个运行JMeter的命令。具体含义如下：

通过执行该命令，JMeter将以非GUI模式加载并运行名为"vip16\fzcs.jmx"的测试计划，并将结果保存到名为"vip16\jtl\fz-003.jtl"的JTL文件中。

summary +     61 in 00:00:17 =    3.7/s Avg:  5683 Min:  4697 Max:  6471 Err:     0 (0.00%) Active: 30 Started: 30 Finished: 0

总结：在00:00:17内，共完成了61个请求，平均每秒处理3.7个请求。平均响应时间为5683毫秒，最短响应时间为4697毫秒，最长响应时间为6471毫秒。错误数为0个（占比0.00%）。当前活跃请求数为30个，已启动的请求数为30个，已完成的请求数为0个。

---

summary +     61 in 00:00:17 =    3.7/s Avg:  5683 Min:  4697 Max:  6471 Err:     0 (0.00%) Active: 30 Started: 30 Finished: 0
summary +    150 in 00:00:28 =    5.3/s Avg:  6056 Min:  4845 Max:  7418 Err:     0 (0.00%) Active: 31 Started: 31 Finished: 0
summary =    211 in 00:00:45 =    4.7/s Avg:  5948 Min:  4697 Max:  7418 Err:     0 (0.00%)
summary +    158 in 00:00:30 =    5.3/s Avg:  5901 Min:  4740 Max:  6967 Err:     0 (0.00%) Active: 32 Started: 32 Finished: 0
summary =    369 in 00:01:15 =    4.9/s Avg:  5928 Min:  4697 Max:  7418 Err:     0 (0.00%)
summary +    167 in 00:00:30 =    5.6/s Avg:  6031 Min:  4308 Max:  9079 Err:     0 (0.00%) Active: 33 Started: 33 Finished: 0
summary =    536 in 00:01:45 =    5.1/s Avg:  5960 Min:  4308 Max:  9079 Err:     0 (0.00%)
summary +    156 in 00:00:30 =    5.2/s Avg:  6145 Min:  4649 Max:  7637 Err:     0 (0.00%) Active: 34 Started: 34 Finished: 0
summary =    692 in 00:02:15 =    5.1/s Avg:  6002 Min:  4308 Max:  9079 Err:     0 (0.00%)
summary +    156 in 00:00:30 =    5.2/s Avg:  6362 Min:  5304 Max:  7328 Err:     0 (0.00%) Active: 35 Started: 35 Finished: 0
summary =    848 in 00:02:45 =    5.1/s Avg:  6068 Min:  4308 Max:  9079 Err:     0 (0.00%)

---

summary +    150 in 00:00:28 =    5.3/s Avg:  6056 Min:  4845 Max:  7418 Err:     0 (0.00%) Active: 31 Started: 31 
Finished: 0

在31个并发用户数，在28秒钟的时间内容，请求了150次。
150 除以 28 rps = 客户端"每秒的请求数"
avg 平均响应时间 ms
Err: 0 (0.00%) 成为率
Active: 31 Started: 31 Finished: 0
活跃的、 启动的、 停止的
	开始、结束的时候， Active Started 不相等是正常的
	在中间的数据 出现 Active Started的也会出现，但是要 谨慎关注
		因为，有一种情况特殊： 当你的电脑，不能产生你期望的并发用户数的时候，这个会有明显的数据差异

---

• 第二个场景， 对登录接口进行负载测试
  • 登录接口，没有去准备登录账户，用注册的账户来登录 ------模拟了，接口之间有关联
  • 登录接口的 最大可接受的并发用户数 区间 [30，40)之间
• 第三种场景： 模拟一个登录行为的负载测试
  • 登录行为: 一个业务行为，不只一个接口，它往往都是由多个接口 一起 实现某个业务
  • 要做的时候 ，肯定是有个接口。
  • 用一个事物控制器，把所有接口，都放置在事物控制器下面，事物控制器，勾选合并

  ---

注意事项：

• 执行测试时，一次测试结束之后，需要停顿一段时间 ，然后再开启下一次测试。

  • 在性能测试时，我们会有大量请求到服务器，服务器在处理这些请求的时候，需要时间，可能会导致服务器资源利用率上升。停止请求，那么就没有请求到服务器了，服务器就可以逐步释放资源，恢复正常。 这个停顿，就是在等待服务器资源慢慢恢复正常。

• 事务控制器的聚合功能，在报告中，没有聚合，在图像界面中聚合了。