Visual Studio 云负载测试平均测试时间似乎很长

Posted 2023-03-23

【中文标题】Visual Studio 云负载测试平均测试时间似乎很长

【英文标题】：Visual Studio Cloud Load Test Average Test Time Seems Long

【发布时间】：2016-03-31 22:59:21

【问题描述】：

我有一个 WebAPI 服务，用于测试托管在 Azure 中的吞吐量。我已将其设置为使用可配置编号（IE webservice/api/endpoint?delay=500）调用 Task.Delay。当我通过 Fiddler 对端点运行时，一切都按预期工作，延迟等。

我使用 VS Enterprise 创建了一个负载测试，并使用我的一些免费云负载测试分钟数在 2 分钟内对 500 个并发用户进行了猛烈抨击。多次运行负载测试后，平均测试时间约为 1.64 秒。我已关闭测试的思考时间。

当我在 Fiddler 中与负载测试同时运行我的请求时，我看到了亚秒级的响应，即使是在向执行按钮发送垃圾邮件时也是如此。我的负载测试有效地做同样的事情并获得 1.64 秒的响应时间。

我错过了什么？

在我的单元测试中运行的代码（然后在我的负载测试中调用）：

var client = new HttpClient  BaseAddress = new Uri(CloudServiceUrl) ;

var response = client.GetAsync($"AuthAsyncTestUri&bankSimTime=bankDelay&databaseSimTime=databaseDelay");

AuthAsyncTestUri 是我的云托管服务的端点。

【问题讨论】：

我认为您需要在问题中添加更多详细信息，否则人们只会猜测问题。从通过 Fiddler 发出的一个呼叫更改为通过 Visual Studio 尝试同时发出 500 个请求是一个巨大的飞跃。您是否按照我的 cmets 中关于我的回答的建议尝试了阶梯式负载？如果是，那么它揭示了什么？

我已编辑问题以包含单元测试的代码。我确实尝试在 5 个用户负载下运行它，并且看到平均测试时间不到 500 毫秒，这与我在 Fiddler 请求中看到的相符。我仍在试图弄清楚为什么 500 用户测试的时间急剧增加，而 Fiddler 请求在 500 用户测试中间运行时保持不变。

你有什么想法，如果单元测试用于负载测试场景，为什么负载测试结果不显示“平均响应时间”？

【参考方案1】：

有几个delay()、sleep()、pause()等方法可用于一个进程。这些方法会导致线程（或其中一些可能的程序或进程）暂停执行。不建议从负载测试中使用的代码调用它们，请参阅Visual Studio Performance Testing Quick Reference Guide（版本 3.6）第 187 页的底部。

Visual Studio 负载测试没有每个虚拟用户一个线程。每个操作系统线程运行许多虚拟用户。在四核计算机上，我看到了使用四个线程为虚拟用户进行的负载测试。

假设负载测试在四核计算机上运行，​​Visual Studio 启动四个线程来执行测试用例。假设一位虚拟用户拨打sleep() 或类似电话。这将暂停该线程，留下三个线程可用于执行其他虚拟用户活动。假设四个虚拟用户几乎同时拨打sleep() 或类似电话。这将停止所有四个线程，并且没有虚拟用户能够执行。

---

回复添加到问题中的以下评论

我确实尝试在 5 个用户负载下运行它，发现平均测试时间不到 500 毫秒，这与我在 Fiddler 请求中看到的相符。我仍在试图弄清楚为什么 500 用户测试的时间急剧增加，而 Fiddler 请求在 500 用户测试中间运行时保持不变。

我认为这条评论突出了问题所在。在用户负载较低时，Visual Studio 负载测试和 Fiddler 测试给出的时间相似。在更高的负载下，负载测试和服务器之间的某些东西会限制吞吐量并导致速度变慢。值得检查运行测试的计算机和被测试系统之间的网络路由。那条路径上是否有任何缓慢的路段？是否有任何段可能将负载测试视为拒绝服务攻击并因此可能减慢流量？

仅运行 2 分钟的测试并不能真正显示测试的运行方式。问题中的详细信息确实说明了在两分钟运行结束时开始了多少测试，完成了多少以及放弃了多少。有可能很多测试用例被放弃了，完成的平均时间是 1.6 秒。

如果您有问题运行的结果，请查看结果的“详细信息”部分。展开图像下方的滑块以包含整个运行。勾选选项（左上角）以突出显示失败的测试。我希望在测试失败的两分钟时会看到很多红色。但是，与采样间隔（在运行设置中）相比，两分钟的运行可能太短而无法看到太多。

在 500 个用户上运行第一次测试告诉你的很少。它告诉您系统可以处理该负载，或者它不能。您需要在几个不同的用户负载下运行测试。然后你开始了解工作和不工作之间的界限在哪里。因此，我建议使用阶梯式负载。

我相信您至少需要再进行一次测试才能了解正在发生的事情。我建议按如下方式运行。设置一分钟的冷却时间。设置阶梯式负载：从 5 个用户开始，因为你知道这很有效。每两秒增加 1 个用户，直到 100 个用户。这将需要 190 秒。在 100 个用户负载下再运行大约一分钟。总共4分10秒。叫它4分钟。加上一分钟的冷却时间（5 分钟）x (100 VU) = 500 VUM，这是每月免费分钟数的一小部分。运行后查看平均测试时间的图表。如果该测试一切正常，那么您可以尝试另一个更快地提升到 500 个用户的测试。

【讨论】：

这是否意味着我不应该相信负载测试平均测试时间？我的单元测试不会休眠，它只是在 URL 上执行 Http GET。该 URL 下的代码执行 Task.Delay，它是 Thread.Sleep 的异步版本。

也许我误解了你的问题。我的回答假设 Task.Delay 在测试套件中。我建议一个更有用的测试使用步进负载模式，从 1 个用户开始，每 2 秒增加 1 个用户，直到（比如说）100 个用户，然后再继续一分钟。总计为 2*100+60(秒) = 260(s)

报告的平均值不错，但您需要分析它们包含的内容。例如，您的服务器的带宽和速度等是多少？例如，服务器和测试执行计算机之间的网络路由是什么。