使用 Visual Studio 2008 进行负载测试：分析结果的麻烦

Posted 2023-03-23

【中文标题】使用 Visual Studio 2008 进行负载测试：分析结果的麻烦

【英文标题】：Load testing using Visual Studio 2008 : troubles with analyzing results

【发布时间】：2009-07-07 15:01:03

【问题描述】：

我使用 Visual Studio Team System 2008 Team Suite 对我的 Web 应用程序进行负载测试（它使用 ASP.MVC 技术）。

负载模式：恒定（这意味着我始终拥有恒定数量的虚拟用户）。 我指定了 1000 个用户的配置来分析我的 Web 应用程序在真正压力条件下的性能。我多次运行相同的负载测试，同时对我的应用程序进行一些更改。

但是在分析负载测试结果时，我发现了一个奇怪的依赖关系：当平均页面响应时间变大时，每秒请求数也会增加！反之亦然：当平均页面响应时间越短，每秒请求数越小.这种情况在用户数量少（5-50个用户）时不会重现。

你如何解释这样的结果？

【问题讨论】：

您是否在单独的计算机上运行负载测试器？

我有一个 Web 应用程序，我在远程 PC 和 VS Team System 上加载测试以在我的 PC 上运行测试。我也尝试使用 VS Test Load Agent 试用版，它是一个单独的产品。它允许创建一个由 1 个测试控制器和许多远程代理组成的测试台。但是控制器和代理之间的连接不稳定，因此似乎不可能使用这个工具。可能原因是我用过试用版。如果你用过VS测试负载代理，我会感谢你的cmets和意见。谢谢

【参考方案1】：

也许这里对“请求/秒”一词有误解。根据我的理解，Requests/Sec 只是表示测试将多少请求推送到应用程序（而不是每秒完成的请求数）。

如果你这样看的话。这可能是有道理的。

高请求/秒将导致更高的平均。响应时间（由于某处的瓶颈，即 CPU 限制、内存限制或 IO 限制）。

因此，随着您的 Requests/Sec 增加，并且您在内存中有大量对象，内存处于压力之下，从而触发垃圾收集，这将减慢您的响应时间。

或者随着您的 Requests/Sec 上升，并且您的 CPU 受到冲击，您可能不得不等待 CPU 时间，从而使您的响应时间变长。

或者当你的 Request/Sec 上升时，你的 SQL 没有正确调整，并且发生阻塞和死锁，从而使你的响应时间变长。

这些只是您可能会看到这些相关性的示例。您可能需要在 CPU、内存使用和 IO（网络、磁盘、SQL 等）方面对其进行更多跟踪

【讨论】：

问题是我的测试配置一直都是一样的（这意味着每次运行负载测试时测试推送到应用程序的请求数都是一样的）。因此，如果我对应用程序的更改使其工作更慢（页面响应时间变长），它应该导致总测试时间变长，请求/秒应该变少。

如果我运行相同的测试并且页面响应时间更长，为什么请求/秒会上升？如果我改变了虚拟用户的数量，你的答案可能是正确的。但我不会更改负载测试配置。

【参考方案2】：

关于该问题的更多细节：我们正在针对标准 ASP.NET aspx 对我们的渲染引擎 [NDjango][1] 进行负载测试。我们用于负载测试的 Web 应用程序非常基础——它由 2 个静态页面组成——没有数据库，没有繁重的处理，只是渲染。我们看到的是，就平均响应时间而言，aspx 预期要快得多，但令我惊讶的是，每秒请求数以及测试期间的请求总数要低得多。 撇开我们正在测试的东西不谈，我同意 Jimmy 的观点，更高的请求率会在很多方面阻塞服务器。但据我了解，这会导致响应时间增加——对吧？ 如果我们得到的数字真的反映了服务器上发生的事情，我看不出这条规则是如何被打破的。所以现在我唯一的解释是数字有偏差——我们配置工具的方式有问题。

[1]:http://www.ndjango.orgNDjango

【讨论】：

您为测试机使用了太多虚拟用户。添加更多测试机器（需要用户代理许可证）或减少虚拟用户数量。

【参考方案3】：

这是正常结果，随着用户数量的增加，您将在服务器上加载每秒更高数量的请求。任何服务器每秒都需要更长的时间来处理更多的请求，这意味着平均页面响应时间会增加。

每秒请求数是衡量应用程序负载的指标，平均页面响应时间是衡量应用程序性能的指标，其中高数量=慢响应。

您最好使用逐步增加的用户数量或逐步将负载应用到服务器的预热期。

另外，在一台测试机上拥有 1000 个虚拟用户，测试机的 CPU 将被完全耗尽。这很可能是扭曲测试结果的原因。考虑虚拟用户的数量，您会发现每秒请求数会达到最大值。添加或删除虚拟用户将导致应用每秒的请求数减少。