我有一个WebAPI服务，我将它放在一起测试Azure中托管的吞吐量。我把它设置为使用可配置的数字调用Task.Delay（IE webservice / api / endpoint？delay = 500）。当我通过Fiddler对端点运行时，一切都按预期工作，延迟等等。
我使用VS Enterprise创建了一个负载测试，并使用了一些免费的云负载测试时间，在2分钟内将500个并发用户用于攻击。在多次运行负载测试后，它表示平均测试时间大约为1.64秒。我已经关闭了考试的思考时间。
当我在Fiddler中同时使用Load测试运行我的请求时，即使发送执行按钮，我也会看到亚秒响应。我的负载测试实际上做了同样的事情并且获得了1.64秒的响应时间。
我错过了什么？
在我的单元测试中运行的代码（然后调用我的负载测试）：
var client = new HttpClient { BaseAddress = new Uri(CloudServiceUrl) };
var response = client.GetAsync($"{AuthAsyncTestUri}&bankSimTime={bankDelay}&databaseSimTime={databaseDelay}");
AuthAsyncTestUri是我的云托管服务的终结点。
答案 0 :(得分：2)
流程可以使用多种delay()，sleep()，pause()等方法。这些方法导致线程（或其中一些程序或进程可能）暂停执行。不建议使用负载测试中使用的代码调用它们，请参阅Visual Studio Performance Testing Quick Reference Guide（版本3.6）的第187页底部。
Visual Studio负载测试每个虚拟用户没有一个线程。每个操作系统线程都运行许多虚拟用户。在四核计算机上，我看到了为虚拟用户使用四个线程的负载测试。
假设在四核计算机上运行负载测试，并且Visual Studio启动四个线程来执行测试用例。假设一个虚拟用户呼叫sleep()或类似。这将暂停该线程，留下三个线程可用于执行其他虚拟用户活动。假设四个虚拟用户几乎同时呼叫sleep()或类似用户。这将停止所有四个线程，并且没有虚拟用户能够执行。
回复添加到问题
中的以下评论我尝试使用5个用户负载运行它，并且平均测试时间小于500毫秒，这与我在Fiddler请求中看到的相匹配。我仍然试图弄清楚为什么500用户测试的时间会急剧上升，而在500用户测试中运行的Fiddler请求保持不变。
我认为这个评论强调了这个问题。在较低的用户负载下，Visual Studio负载测试和Fiddler测试给出了类似的时间。在负载较高时，负载测试和服务器之间的某些东西会限制吞吐量并导致速度下降。值得检查运行测试的计算机与正在测试的系统之间的网络路由。那条路上有没有慢节？是否有任何段可能将负载测试视为拒绝服务攻击，因此可能会减慢流量？
运行测试只需2分钟并不能真正显示测试的运行方式。问题中的详细信息可以告诉我们在两分钟结束时完成了多少次测试，完成了多少次以及放弃了多少次测试。许多测试案例可能被放弃，完成的平均时间为1.6秒。
如果您有问题的结果，请查看结果的“详细信息”部分。展开图像下方的滑块以包含整个运行。勾选选项（左上角）以突出显示失败的测试。我希望在测试失败的两分钟内看到很多红色。但是，与采样间隔（在运行设置中）相比，两分钟运行可能太短，看得太多。
对500名用户进行第一次测试告诉你很少。它告诉您系统应对该负载或不处理。您需要在几个不同的用户负载下运行测试。然后你开始了解工作和不工作之间的界限。因此我建议使用阶梯式负载。
我相信您至少需要再进行一次测试才能了解正在发生的事情。我建议按如下方式进行。设置一分钟的冷静期。设置一个步进负载：从5个用户开始，因为你知道这是有效的。每两秒增加1位用户，直到100位用户。那需要190秒。在该100个用户负载下运行大约一分钟。总共4分10秒。叫它4分钟。在一分钟内加入冷却使（5分钟）x（100 VU）= 500 VUM，这是每月免费分钟的一小部分。运行后查看平均测试时间的图表。如果在该测试中一切正常，那么您可以尝试使用另一个更快速地说500个用户。