ASP.NET、IIS /CLR 线程和请求与同步与异步编程有关

Question

我只是想在这里澄清一些概念。如果有人愿意分享他们在这方面的专业知识，我们将不胜感激。

以下是我对 IIS 如何与线程相关的工作的理解，如果我错了，请纠正我。

HTTP.sys

据我了解，对于 IIS 6.0（我将暂时离开 IIS 7.0），Web 浏览器发出请求，被 HTTP.sys 内核驱动程序接收，HTTP.sys 将其交给 IIS 6.0 的线程池（I/O 线程？）等释放自身。

IIS 6.0 线程/线程池

IIS 6.0 的线程返回将其交给 ASP.NET，ASP.NET 将临时 HSE_STATUS_PENDING 返回给 IIS 6.0，这样可以释放 IIS 6.0 线程，然后将其转发给 CLR 线程。

CLR 线程/线程池

当 ASP.NET 在 CLR 线程池中获取空闲线程时，它会执行请求。如果没有可用的 CLR 线程，它会在应用程序级队列中排队（性能很差）

所以基于之前的理解，我的问题如下。

1. 在同步模式下，这是否意味着每 1 个 CLR 线程有 1 个请求？

   *) 如果是这样，在 1 个 CPU 上可以处理多少个 CONCURRENT 请求？还是我应该反过来问？每 1 个 CPU 如何允许 CLR 线程？比如说，允许 50 个 CLR 线程，这是否意味着它在任何给定时间都被限制为 50 个请求？使困惑。

2. 如果我将“processModle”配置中的“requestQueueLimit”设置为 5000，这究竟意味着什么？您可以在应用程序队列中排队 5000 个请求吗？那真的不是很糟糕吗？既然应用程序队列的性能很差，为什么还要设置这么高呢？

3. 如果您正在编程异步页面，那么在上述过程中它究竟从哪里开始受益？

4. 我研究发现，默认情况下，IIS 6.0 的线程池大小为 256。5000 个并发请求进来，由 256 个 IIS 6.0 线程处理，然后 256 个线程中的每一个都将其交给 CLR 线程我猜默认情况下甚至更低。这本身不是异步的吗？有点困惑。另外，同步模式下瓶颈在何时何地开始出现？并在异步模式下？ （不确定我是否有任何意义，我只是感到困惑）。

5. 当 IIS 线程池（全部 256 个）忙时会发生什么？

6. 当所有 CLR 线程都忙时会发生什么？ （我假设所有请求都在应用程序级队列中排队）

7. 当应用程序队列超过 requestQueueLimit 时会发生什么？

非常感谢您的阅读，非常感谢您在这方面的专业知识。

Answer 1

您对向 CLR 的移交过程非常了解，但有趣的地方在于：

• 如果请求的每一步都是 CPU 绑定的/否则是同步的，是的：该请求将在其生命周期内占用该线程。

• 但是，如果请求处理任务的任何部分超出了纯托管代码（数据库连接、文件读/写等）之外的任何异步或什至任何与 I/O 相关的任务，则有可能（如果不可能的话）这会发生：

  • 请求进入 CLR 领域，由线程 A 接收

  • 请求调用文件系统

  • 在幕后，到非托管代码的转换发生在某个级别，这会导致 IO 完成端口线程（与普通线程池线程不同）在类似回调的方式中分配方式。

  • 一旦发生切换，线程 A 返回回到线程池，在那里它能够为请求提供服务。

  • 一旦 I/O 任务完成，执行就会重新排队，假设线程 A 正忙 - 线程 B 接手请求。

这种“有趣”的行为也称为“线程敏捷性”，这是尽可能避免在 ASP.NET 应用程序中使用任何线程静态的原因之一。

现在，回答您的一些问题：

• 请求队列限制是在请求开始被完全丢弃之前可以“排队”的请求数。例如，如果您有一个异常“突发”的应用程序，您可能会收到很多非常短暂的请求，那么将其设置为高可以防止丢失的请求，因为它们会在队列中聚集，但同样会很快耗尽。

• 异步处理程序允许您创建与上述场景相同的“完成后呼叫我”类型的行为；例如，如果您说需要进行 Web 服务调用，则通过说一些 HttpWebRequest 调用同步调用该调用将默认阻塞直到完成，锁定该线程直到完成。异步调用相同的服务（或异步处理程序，任何 Begin/EndXXX 模式......）允许您控制谁实际被捆绑 - 您的调用线程可以继续执行操作，直到该 Web 服务返回，这实际上可能是在请求已完成。

1234563不服务请求。