我试图理解最近Azure云负载测试的结果，我们针对其中一个API运行的结果Azure负载测试。了解虚拟用户如何影响性能
在测试API时，我配置了负载测试虚拟用户没有思维时间。实质上，每当虚拟用户收到响应时，它立即发送另一个请求。
我们也没有使用任何类型的用户会话或缓存每个用户的任何数据。这是一个基本测试，将一些JSON发布到API上的端点，然后对接收到的数据进行一些计算。
看来，通过改变虚拟用户的数量，我们可以使服务更高性能。我的意思是，它可以更快地响应并且仍然每秒处理更多的请求。
两个负载测试的结果如下所示。
第一个测试告诉我，我们的API能够在2分钟内处理60k个请求。
我无法理解的是，为什么添加更多的虚拟用户，增加了平均响应时间并降低了RPS，这又导致API仅在2分钟内处理55k请求。
为什么API现在只能处理460个RPS，而我们已经知道它可以处理500个RPS？
这里有3个问题： 1.为什么更多的虚拟用户增加响应时间; 2.为什么更多的VU会降低RPS; 3.为什么更多的VU减少了总的请求。
这里有解释：
更多并发的VU创建需要在服务器上更多的资源，更多的并发会话提高服务器的处理时间和响应时间（例如会话上下文，队列的大小，线程并发）从客户的角度来看。
只有当负载生成器发出频率恒定的请求时，在这种情况下，RPS的降低才会不一致。实际上，在发出请求之后，每个VU等待直到收到响应。由于服务器响应速度变慢，等待时间增加，导致RPS下降。 这个问题有第二个答案。由于负载生成器性能容量有限，因此模拟更多的VU需要客户端上的更多资源，这可能会导致请求发出延迟。尽管您将测试配置为零思考时间，但负载生成器可能会无意中注入延迟，从而导致额外的RPS减少。
总请求数量与VU和RPS的数量成比例。显然，在你的情况下，RPS减少会产生更大的影响，并且总请求数量减少。
一般情况下，降低所引起的负载测试增加VU RPS的效果看起来像一个悖论，当在现实中却并非如此。
没有“确切”的单一原因，但请记住，随着您增加负载生成器的数量，您还在增加连接数，服务器上并行操作的数量等。您不能假设，通过随着时间的推移增加用户负载，您将继续获得更好的吞吐量和响应时间。事实上，有时你会增加负载，并在性能图上找到难以捉摸的“曲线拐点” - 其中延迟高峰（伴随请求失败）以及吞吐量急剧下降。从负载测试的角度来看，这将是一件好事，因为您现在对于您现有的软件+基础架构在交易速率等方面可以期待什么相当好的想法。
您需要进一步深入研究以确定确切原因，但它可能很容易与线程池耗尽，内存问题，CPU问题，磁盘问题，特定资源（例如缓存或数据库）上的瓶颈，网络饱和等相关。
“您现在对于您现有的软件+基础架构在交易速率等方面的期望有了一个相当好的想法”。这就是现在，我现在不知道。 我是负载测试，因为我想确保API可以应付500 RPS。从技术上来说，第一次测试处理了500个RPS，没有问题并且响应迅速。 我不知道，虽然现场环境会更接近。 200个虚拟用户或300个虚拟用户。 – Steve
我在服务本身有一些性能计数器，所以我可以看到，当有更多的用户时，服务需要更长的时间来响应。 所以我不认为负载发生器是无意中在我的测试中注入延迟。正如你所建议的那样，它可能与更多的当前会话有关。我会继续挖掘。谢谢 – Steve