我使用 Visual Studio Team System 2008 Team Suite 对我的 Web 应用程序进行负载测试（它使用 ASP.MVC 技术）。
负载模式：恒定（这意味着我始终拥有恒定数量的虚拟用户）。我指定 1000 个用户的配置来分析我的 Web 应用程序在真正压力条件下的性能。我多次运行相同的负载测试，同时对我的应用程序进行一些更改。
但是在分析负载测试结果时，我发现了一个奇怪的依赖关系：当平均页面响应时间变大时，每秒请求数也会增加！反之亦然：当平均页面响应时间越少，每秒请求数越少。这种情况用户量少（5-50个用户）时不复现。
你如何解释这样的结果？
也许这里对 Requests/Sec 一词有误解。根据我的理解，Requests/Sec 只是表示测试将多少请求推送到应用程序（而不是每秒完成的请求数）。
如果你这样看。这可能是有道理的。
高请求/秒将导致更高的平均。响应时间（由于某处的瓶颈，即 CPU 限制、内存限制或 IO 限制）。
因此，随着您的 Requests/Sec 增加，并且您在内存中有大量对象，内存处于压力之下，从而触发垃圾收集，这将减慢您的响应时间。
或者随着您的 Requests/Sec 上升，并且您的 CPU 受到重击，您可能不得不等待 CPU 时间，从而使您的响应时间更长。
或者当您的请求/秒上升时，您的 SQL 没有正确调整，并且发生阻塞和死锁，从而使您的响应时间变长。
这些只是您可能会看到这些相关性的示例。您可能需要在 CPU、内存使用和 IO（网络、磁盘、SQL 等）方面进行更多跟踪。
关于这个问题的更多细节：我们正在针对标准 ASP.NET aspx 对我们的渲染引擎 [NDjango][1] 进行负载测试。我们用于负载测试的 Web 应用程序非常基础——它由 2 个静态页面组成——没有数据库，没有繁重的处理，只是渲染。我们看到的是，就平均响应时间而言，aspx 预期要快得多，但令我惊讶的是，每秒的请求数以及测试期间的请求总数要低得多。撇开我们正在测试的东西不谈，我同意 Jimmy 的观点，更高的请求率会在很多方面阻塞服务器。但据我了解，这会导致响应时间增加——对吧？如果我们得到的数字真的反映了服务器上发生的事情，我看不出这条规则是如何被打破的。
[1]：http: //www.ndjango.org NDjango
这是正常结果，随着用户数量的增加，您将以每秒更高数量的请求加载服务器。任何服务器每秒都需要更长的时间来处理更多的请求，这意味着平均页面响应时间会增加。
每秒请求数是衡量应用程序负载的指标，平均页面响应时间是衡量应用程序性能的指标，其中高数量=慢响应。
您最好使用逐步数量的用户或将负载逐渐应用于服务器的预热期。
另外，单台测试机有1000个虚拟用户，测试机的CPU绝对会被刷爆。这很可能是扭曲测试结果的原因。考虑虚拟用户的数量，您会发现每秒请求数会达到最大值。添加或删除虚拟用户将导致应用程序每秒的请求数减少。