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