对于 Java 中的 rest api 应用程序，我们计划执行负载测试。但初步结果有点令人困惑。使用 jmeter 进行脚本开发后。 1. 我们为 1 个 vuser、2 个 vusers、5vuser、10 个 vusers 和 25 个 vusers 执行脚本 2. 每次测试执行30分钟，加速近5秒。 3.每个请求都有从2秒到3秒的随机思考时间。
执行此测试时，我们看到对于少数 API，2、5、10 个 vuser 的 95% 响应时间远小于 1 个 vuser。但是雄猫重新启动后的相同测试给出了不同的结果
我对随着用户数量的增加，响应时间是如何减少的感到困惑。
tomcat实例未重新启动时的响应时间图：https://i.stack.imgur.com/BaBYl.jpg
tomcat实例重新启动时的响应时间图： https://i.stack.imgur.com/J2HpI.jpg
有一个Java运行时功能：即时编译，Java字节码在~1500次调用(默认值(后被转换为本机代码，可通过-XX：CompileThreshold属性进行控制。
这可能是您所面临的情况的解释：Java 运行时根据函数的使用情况优化函数，因此如果您反复调用函数，函数执行时间可能会减少。
也不要指望 2 个虚拟用户的响应时间会比 1 个虚拟用户的响应时间高 2 倍。应用程序可能会扩展到一定程度，当您增加负载时，吞吐量将增加，响应时间将保持不变。
在某些时候，响应时间将开始增长，吞吐量将下降，这称为性能瓶颈，但是考虑到当前的现代硬件，您遇到 25 个用户的应用程序限制的可能性很小。
因此，请考虑应用以下性能测试类型：
负载- 测试：从 1 个用户开始，逐渐增加负载，直到预期的虚拟用户数量，同时查看吞吐量和响应时间。如果随着用户数量的增加，无法检测到性能下降 - 则可以报告应用程序已准备好用于生产
- 压力测试：从 1 个用户开始，逐渐增加负载，直到响应时间开始增长或错误开始发生。这将为您提供信息，例如它可以支持的最大用户数以及首先失败的组件是什么。
详细信息：为什么"正常"负载测试是不够的
检查您的 API 是否不会针对大规模无效响应返回 200。
为此，请使用响应断言。