最初，我已经对100位用户进行了10分钟的负载测试，并在数据库中插入了1000条记录，用于以下方案。
然后我用200个用户运行相同的负载测试10分钟，插入了1100条记录，没有任何错误日志或死锁。 我的问题是当我们将线程组数量从100增加/加倍到200时，记录插入也应该是两倍或大约两倍。那为什么不发生？与请求/样本数量相同的情况。
答案 0 :(得分：0)
您的测试throughput达到了每分钟约110条记录的最大值。换句话说，您在客户端或服务器上存在瓶颈，它不允许200个用户同时和/或在相同的时间内处理请求（某些用户等待他们可以开始处理请求，或者每个用户请求需要更长时间，因此请求总数更低。）
您可以解决一些瓶颈（如果它们与脚本，JMeter配置或JMeter机器相关），其他瓶颈必须在服务器端解析（由任何有权访问它的人），有些瓶颈根本无法解决（它们是您应用的真正瓶颈）。
在不了解您的申请的情况下，很难提出超出一般情况的任何建议＆＃34;清单＆＃34;项目：
验证JMeter脚本并检查它是否有可能等待的任何位置，需要很长时间，等等。例如，如果您的加速期过高，则可能是第一次＆＃34;用户将在＆＃34; last＆＃34;之前完成执行。用户甚至开始了。可编写脚本的采样器，处理器前后处理器也可能导致延迟。
确保正确配置JMeter以处理200个并发线程。例如，如果JMeter堆设置得太低，可能是JMeter非常慢，因为它总是需要运行GC。请参阅this有关如何查看和配置内存的问题（它讨论内存不足错误，但即使没有错误，内存不足也会导致速度缓慢）
确保正确配置JMeter计算机，以允许同时创建200多个HTTP连接。 Windows和Linux机器上的一个常见问题是人们认为它们可以有65535个连接（作为最大端口数），但实际上，Windows和Linux都限制了默认使用的端口数量。此外，使用端口可能会在TIME_WAIT或CLOSE_WAIT状态下保持几分钟，这使其无法使用。结果，用完端口很常见。以下是Windows和Linux上如何监控和解决此问题的方法。
检查JMeter机器的整体性能：它是否有足够的CPU，内存;是交换记忆等等。
如果以上都不是问题，您需要查看请求如何到达服务器。如果客户端能够发送200个并发请求（您应该在之前的步骤中建立），但服务器以较慢的速率接收它们，那么网络中的某些内容可能会减慢速度。例如，慢速DNS解析或JMeter与服务器之间的慢速路由可能会导致问题。
客户端上的第3项也适用于服务器。
如果请求的确以与从客户端发送的速度相同的速度到达服务器，则服务器的处理可能会随着并行请求数量的增加而减慢。这是你在dev和devOP领域的地方，可能需要与他们合作来识别服务器端的瓶颈。它可能是Web或应用程序服务器的配置，应用程序本身，... app上的任何东西。
性能测试是10％执行，90％分析和识别瓶颈，所以在这里。