异步操作方法对 IIS 有什么影响？

Question

我需要帮助来了解异步操作方法如何提高 IIS（以及最终我的应用程序）的性能。

首先，我尝试使用以下代码和设置创建服务器不可用（503）

• 应用队列长度：10
• IIS - 每个处理器的线程数限制：2
• 处理器：4

使用 SOAP UI 发送了 20 个请求，当从浏览器尝试时，浏览器显示 503，这正是我所期望的。

然后我对代码进行了以下更改

使用 SOAP UI 再次发送 20 个请求，当从浏览器尝试时，浏览器再次显示 503，这是我没想到的。

不会 async 和 await 释放线程以接受新连接吗？

我对以下的理解是否正确

1. 服务器在任何给定时间可以接受的最大并发请求数是：（每个处理器的 IIS 线程限制 * 处理器数 + 应用程序队列长度）在我的情况下为 18？
2. 在同步操作方法的情况下，第 19 个请求会得到 503？

Answer 1

定义异步操作方法不会影响 IIS 可以处理多少相同类型的请求。当您说在 Task.Delay 调用期间释放线程本身时，您是正确的，但请求仍在队列中。

仅当您向像这样的异步 TimeOnServer 操作发送一些请求，以及其他一些可以使用更多线程的不同类型的请求时，您才会看到差异- 例如，使用 PLINQ 执行一些并行工作。在这种情况下，您的“其他”请求将以更高的速度提供服务。

这是一篇古老但非常有用的文章，它清楚地描述了好处：

异步编程： Stephen Cleary介绍 ASP.NET 上的 Async/Await

Answer 2

正如 Mikl\xc3\xb3s 所指出的，异步请求会将其线程交给 ASP.NET 线程池，但请求本身仍然处于活动状态。因此，要了解异步操作的好处，您需要限制线程池而不是限制队列。

\n\n

另一个常见错误（尤其是浏览器测试时）是，默认情况下 ASP.NET 会话状态将序列化同一会话的请求。

\n\n

我这里有一个要点有一个要点演示了异步调用如何产生线程。

\n