我得到以下结果，即使增加线程数，吞吐量也没有变化。
方案1：
线程数：10
准备阶段：60
吞吐率：5.8 / s
平均：4025
方案2：
线程数：20
准备阶段：60
吞吐率：7.8 / s
平均：5098
方案3：
线程数：40
准备阶段：60
吞吐率：6.8 / s
平均：4098
我的JMeter文件由一个包含单个GET的ThreadGroup组成。
当我执行响应速度更快（小于300毫秒）的端对端请求时，我可以获得的吞吐量大于每秒50个请求。
您能看到这个瓶颈吗？
响应时间和吞吐量之间有关系吗？
最佳答案
在理想情况下，如果将线程数增加2倍，则吞吐量应增加相同的倍数。
实际上，“理想”方案是无法实现的，因此它看起来像是应用程序中的瓶颈。识别瓶颈的过程通常如下所示：
修改测试配置以逐渐增加负载，即从1个虚拟用户开始，并在5分钟内将负载增加到100个虚拟用户
运行测试并查看Active Threads Over Time，Response Times Over Time和Server Hits Per Second侦听器。这样，您就可以将增加的负载与增加的响应时间相关联，并确定性能开始下降的点。有关更多信息，请参见What is the Relationship Between Users and Hits Per Second?
一旦弄清什么是saturation point，您需要知道是什么阻止您的应用程序处理更多请求，其原因可能是：
应用程序仅缺少资源（CPU，RAM，网络，磁盘等），请确保监视上述资源，这可以使用JMeter PerfMon Plugin完成
基础结构配置不适合高负载（即应用程序或数据库线程池设置不正确）
问题出在您的应用程序代码中（效率低下的算法，大对象，数据库查询缓慢）。可以使用profiler tool获取这些项目
还要确保您遵循JMeter Best Practices，因为可能由于JMeter负载生成器端资源不足或JMeter配置不正确（堆太低，在GUI模式下运行测试）而导致JMeter无法足够快地发送请求的情况，使用侦听器等）
关于performance - 吞吐量值是否与JMeter中请求的响应时间有关？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48893095/