Thomas Marquardt的following篇文章描述了IIS如何处理ASP.Net请求、可配置为运行的最大/最小CLR工作线程/托管IO线程、涉及的各种请求队列及其默认大小.
现在，根据本文，IIS 6.0中发生了以下情况:
- ASP.NET接收来自IIS IO线程的请求，并将"HSE_STATUS_PENDING"发布到IIS IO线程
- 请求被移交给CLR工作线程
- 如果请求的延迟很高，并且所有线程都被占用(线程数接近httpRuntime.minFreeThreads)，那么请求将被发布到应用程序级请求队列(该队列针对每个AppDomain)
-
ASP.NET还判断并发执行的请求数.本文声明"如果并发执行的请求数太高"，它会将传入请求排队到ASP.NET全局请求队列(这是针对每个工作进程)(请判断更新2)
我想知道ASP.NET认为当前执行它的请求数太高，然后开始将请求排队到全局ASP.NET请求队列的"阈值"是多少？
我认为此阈值将取决于最大工作线程数的配置，但可能会有一些公式，ASP.NET将根据该公式确定并发执行的请求数太高，并开始将请求排队到ASP.NET全局请求队列.这个公式会是什么呢？或者此设置是可配置的吗？
Update
I read through the article again and in the comments sections I found this:
1)在IIS 6和IIS 7classic 模式下，每个应用程序(AppDomain) 有一个队列，它使用该队列来维护Worker的可用性 螺纹.此队列中的请求数在以下情况下会增加 可用工作线程的百分比低于由 httpRuntime minFreeThread.当由指定的限制 超过httpRuntime appRequestQueueLimit，则请求为 拒绝，状态代码为503，并且客户端收到 HttpException异常，并显示消息"Server Too Busy".还有一个 ASP.NET性能计数器"应用程序队列中的请求"，该计数器 指示队列中有多少个请求.是的，CLR线程 池是由.NET ThreadPool类公开的池.
2) requestQueueLimit的名称很差.它实际上限制了
Update 2