全网火爆，Jmeter性能场景设计 - 普通性能场景+分析性能指标（一）

目录：导读

前言

性能场景设计是性能测试中非常重要的一个环节，因为设计一个好的场景能让你更贴近真实的业务场景，更能分析出服务器的性能情况。

常见的性能场景有6种：
普通性能场景
阶梯性能场景（负载测试场景）
压力测试场景
面向目标场景（使用lr的话，这个很容易实现。Jmeter则需要些方法）
混合场景（混合是指不同数量的人向不同接口发起请求）
有时间规律的场景

今天我们主要讲解普通性能测试场景（其它场景后续更新）

普通性能场景设计
在jmeter中，普通性能场景使用的还是普通的线程组，即下图这个：

请添加图片描述

说明：

线程数：模拟的并发用户数量，即并发用户数

jmeter本身是没有对线程数做限制的
+但是jmeter启动这些并发用户数时，需要消耗资源，它受电脑cpu的主频限制，一台电脑不可能创建无限量的并发用户数，主频是3GHz的电脑大约可以产生3000个线程数。（来自官方的说法）。
+在实践中发现，http协议的脚本，主频是2GHz以上的电脑，大概能产生1500~2000个并发用户数产生，但可能会报错；因此保守点，推荐普通的电脑，一台1000个并发用户数即可。
如果想模拟超过1千的并发用户数，推荐考虑使用分布式。

Ramp-up时间（秒）：启动所有线程数的时间

比如设置500个线程数，Ramp-up设置5秒，那就是5秒内会启动所有这500个线程数。
请注意，这启动数量是不定的，就算Ramp-up设置是5秒，它并不会平均每秒启动100个；它是在这5秒内启动500个，即有可能第1秒就启动了200个，第二秒启动了100个，第三秒启动完剩下的200个了。
另外线程数一定要设置在一个合理的范围，否则就算设置了Ramp-up，也一样无法启动所有的线程数！
另外，网上很多人会说这是加速时间，但这实际跟加速没有任何关系，所谓的加速时间只是这个单词的直译而已。
并发用户在产生之后就会立刻去执行，并不是说设置了5秒的Ramp-up，就会等5秒后再执行。也因为有时间先后的问题，如果一个线程组内有多个接口，每个用户去请求的未必是相同的接口；也因此jmeter更多的是做广义上的并发（指同一件时间内服务器处理多个请求）
Ramp-up默认大于等于1秒
一般情况下，500个并发用户，Ramp-up设置2_4秒；5001000个并发用户，Ramp-up设置5秒；>1000个并发用户，Ramp-up设置5~8秒。
不过具体的设置描述要具体情况具体分析，但有一个原则是不变的：Ramp-up时间再总执行时间中占比要很低。

循环次数：每个用户的执行次数

默认大于等于1秒
“永远”复选框，勾选之后会一直循环执行，直到点击停止按钮为止。通常勾选永远之后会集合调度器一起使用。

调度器：需要同时勾选调度器和循环次数中的“永远”复选框才能生效。

持续时间：持续运行的时间

达到时间后会自动结束。
结束时，哪怕用户没有执行完所有接口，也会结束，不会等待用户全部执行完成。

启动延迟：延迟N秒启动

注意，在等待的过程中并不会生成并发用户数

场景实战

这里有一个注册接口，线程组的配置如下：
线程数：30
Ramp-up： 1
持续时间：300秒（5分钟）

请添加图片描述

下面这个是响应时间的图

请添加图片描述

下面这个是聚合报告的图

请添加图片描述

结果分析
从上面的聚合报告里，可以做一个简单的性能分析，首先提取性能指标：
响应时间：聚合报告里，平均响应时间的价值没有90%百分位和95%百分位来得高，因此这里先只记录90%和95%两个的数值： 1.225秒和1.290秒。
网络：我现在用的是100兆的带宽，理论上可以支持12800KB的传输。而从聚合报告里显示只接收了6.42KB/秒和10.04KB/秒。由此可判断当前并没有网络瓶颈。
TPS：由于没有网络瓶颈，因此吞吐量可以当做是TPS，所以目前的TPS是28.3/秒。

最后是两个已知的值：
并发用户数：30
运行时长：5分钟

根据上面指标，可以得到一个性能结果：
按照用户满意指数，一个接口用户愿意等待的时间是1.5s，在30个并发用户数时，我的接口的响应时间是1.225s，未超出用户满意指数但也很接近了；再然后TPS是28.3/秒，而并发用户数是30个，tps<user，相当于每人每秒发送约0.94个接口。结论是：注册接口的性能大约只能支持30个左右的并发用户数，再增加只会越来越满。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图