相对于正确配置的同步模型，异步模型真的能提高吞吐量吗？

Question

每个人都知道异步可以为您提供“更好的吞吐量”、“可扩展性”以及在资源消耗方面更高效。在进行下面的实验之前，我也想到了这种（简单的）方式。它基本上告诉我们，如果我们考虑异步代码的所有开销并将其与正确配置的同步代码进行比较，它几乎不会产生性能/吞吐量/资源消耗优势。问题：与正确配置线程池的同步代码相比，异步代码实际上执行得更好吗？可能是我的性能测试以某种戏剧性的方式存在缺陷？测试设置：两个 ASP.NET Web API 方法，JMeter 试图用 200 个线程线程组调用它们（30 秒恢复时间）。[HttpGet][Route("async")]public async Task<string> AsyncTest(){    await Task.Delay(_delayMs);    return "ok";}[HttpGet][Route("sync")]public string SyncTest(){    Thread.Sleep(_delayMs);    return "ok";}这是响应时间（对数刻度）。请注意，当线程池注入足够多的线程时，同步代码如何变得更快。如果我们事先（通过SetMinThreads）设置线程池，它会从一开始就表现出色async。你会问资源消耗怎么样。“线程在 CPU 时间调度、上下文切换和 RAM 占用方面的成本很高”。没那么快。线程调度和上下文切换是高效的。就堆栈使用而言，线程不会立即消耗 RAM，而只是保留虚拟地址空间并仅提交实际需要的一小部分。让我们看看数据怎么说。即使线程数量更多，同步版本的内存占用也更小（映射到物理内存的工作集）。

Answer 1

每个人都知道异步可以为您提供“更好的吞吐量”、“可扩展性”以及在资源消耗方面更高效。

可扩展性，是的。吞吐量：视情况而定。每个异步请求都比等效的同步请求慢，因此只有当可伸缩性发挥作用时，您才会看到吞吐量优势（即，请求数多于可用线程数）。

与正确配置线程池的同步代码相比，异步代码实际上执行得更好吗？

好吧，要注意的是“正确配置的线程池”。您假设您可以 1) 预测您的负载，以及 2) 有一个足够大的服务器来处理每个请求使用一个线程。对于许多（大多数？）现实世界的生产场景，这两个或其中一个都不正确。

来自我关于异步 ASP.NET 的文章：

为什么不增加线程池的大小[而不是使用异步]？答案是双重的：异步代码比阻塞线程池线程扩展得更远、更快。

首先，异步代码比同步代码扩展得更远。使用更真实的示例代码，ASP.NET 服务器（经过压力测试）的总体可扩展性呈现成倍增长。换句话说，异步服务器可以处理数倍于同步服务器的连续请求数（两个线程池都已调至该硬件的最大值）。但是，这些实验（不是我做的）是在平均 ASP.NET 应用程序的预期“现实基线”上完成的。我不知道相同的结果如何转移到 noop 字符串返回。

其次，异步代码比同步代码扩展得更快。这个很明显；同步代码可以很好地扩展到线程池线程的数量，但扩展速度不能快于线程注入率。因此，如响应时间图的开头所示，您对突然重载的响应非常缓慢。

我认为你所做的工作很有趣；我对内存使用差异（或者更确切地说，没有差异）感到特别惊讶。我很乐意看到你把它写成一篇博文。建议：

• 使用 ASP.NET Core 进行测试。旧的 ASP.NET 只有一个部分异步的管道；ASP.NET Core 对于同步与异步的更“纯粹”的比较是必要的。

• 不要在本地测试；这样做有很多注意事项。我建议选择 VM 大小（或单实例 Docker 容器或其他）并在云中测试可重复性。

• 除了负载测试之外，还可以尝试压力测试。不断增加负载直到服务器完全不堪重负，然后查看异步和同步服务器如何响应。

最后提醒一下（也来自我的文章）：

请记住，异步代码不会取代线程池。这不是线程池或异步代码；它是线程池和异步代码。异步代码允许您的应用程序充分利用线程池。它使用现有的线程池并将其增加到 11 个。

Answer 2

真正的异步代码 (I/O) 更具可扩展性，因为它释放线程池线程用于其他工作而不是阻塞它们。所以，对于相同数量的线程来说，它可以处理更多的请求。

但这样做的代价是更多的控制数据结构和更多的工作。因此，（除了节省线程池线程外）它会消耗更多资源（内存、CPU）。

一切都与可用性有关，而不是性能。