无法通过运行Jmeter脚本来实现预期吞吐量，因为预期吞吐量越来越高，但却越来越低。
通过以每秒1000个请求为目标运行Jmeter脚本(业务SLA)，因此使用了"恒定吞吐量计时器"或"吞吐量成形计时器"，如以下查询所示。
- 恒定吞吐量计时器：目标-60000/分钟(60秒)-所有活动线程，线程(用户)-200，增量-1秒，持续时间：1小时。或用户-2000，或尝试使用10000个用户
结果：结束执行，吞吐量显示为50/秒，平均响应时间为50秒。
Jmeter：测试5个用户的场景，增加1小时以触发10000个请求
无法提高jmeter 的平均吞吐量
- 吞吐量整形计时器：如上所述反映设置
在这两种情况下，"吞吐量"都在50秒左右，平均响应时间在30秒左右。
从服务器指标来看，CPU和内存消耗非常少，仅为3%左右。
因此，由于服务器资源使用不多，预期的"吞吐量"很高，如果"吞吐量"较低，并且使用Forever连续发送请求以查看是否可以获得500个响应代码错误，则只会增加平均响应时间并降低吞吐量，但不会获得500个回应代码错误。
在获得套接字异常一段时间后，Jmeter运行时出现连接重置问题，但在服务器端没有看到故障。
在这里经历了类似的查询，但无法理解何时服务器资源使用不多，并且根据服务器平台SLA，它支持1000 RPS，但无法通过Jmeter实现。
根据CTT计算：RPS*/1000
1000*5000/1000=50000(应该提供高达50K的线程？但是我们的SLA仅适用于200个用户)。
- 可能是因为服务器的响应速度不够快。低CPU和内存消耗意味着服务器有足够的空间，但应用程序服务器配置可能不正确，因此服务器无法充分利用其硬件资源。另一个原因可能是应用程序代码中使用的算法效率低下，您可以使用探查器工具来查看在进行加载时发生了什么
- 可能是JMeter无法足够快地发送请求。请确保运行JMeter的机器没有过载，您在非GUI模式下运行您的JMeter测试，并且通常遵循JMeter最佳实践。如果一台机器无法创建所需的负载，您也可以尝试在分布式模式下运行JMeter