现在根据文章，以下发生在IIS 6.0：
> ASP.NET从IIS IO线程中获取请求并向IIS IO线程发布“HSE_STATUS_PENDING”
>请求被移交给CLR Worker线程
>如果请求具有高延迟并且所有线程都被占用(线程计数接近httpRuntime.minFreeThreads)，则请求被发布到应用级请求队列(这个队列是根据AppDomain)
>另外ASP.NET检查并发执行请求的数量。文章指出，“如果并发执行请求的数量太高”，它将传入的请求排队到ASP.NET全局请求队列(这是每个工作进程)(请检查更新2)
我想知道什么是“阈值”什么时候ASP.NET认为当前执行它的请求数量太高，然后开始排队请求到全局ASP.NET请求队列？
我认为这个阈值将取决于最大数量的工作线程的配置，但可能有一些公式，ASP.NET将确定并发执行请求的数量太高，开始排队请求到ASP.NET全局请求队列。这个公式有什么可能？或者此设置是否可配置？
更新
1) On IIS 6 and in IIS 7 classic mode,each application (AppDomain)
has a queue that it uses to maintain the availability of worker
threads. The number of requests in this queue increases if the number
of available worker threads falls below the limit specified by
httpRuntime minFreeThreads. When the limit specified by
httpRuntime appRequestQueueLimit is exceeded,the request is
rejected with a 503 status code and the client receives an
HttpException with the message “Server too busy.” There is also an
ASP.NET performance counter,“Requests In Application Queue”,that
indicates how many requests are in the queue. Yes,the CLR thread
pool is the one exposed by the .NET ThreadPool class.2) The requestQueueLimit is poorly named. It actually limits the
maximum number of requests that can be serviced by ASP.NET
concurrently. This includes both requests that are queued and
requests that are executing. If the “Requests Current” performance
counter exceeds requestQueueLimit,new incoming requests will be
rejected with a 503 status code.
因此，基本上requestQueueLimit限制排队的请求数(我假设它将在应用队列中排队的请求数加上全局ASP.Net请求队列加上当前执行的请求数)并且正在执行。尽管这不回答原始问题，它提供了有关我们何时可能收到503服务器忙错误的信息，因为大量的并发请求/高延迟请求。
(检查更新2)
更新2
在我的部分有一个错误的理解。我混淆了IIS 6和IIS 7的说明。
基本上当ASP.NET以集成模式在IIS 7.5和7.0上托管时，应用程序级队列不再存在，ASP.NET维护一个全局请求队列。
因此，如果执行请求的数量被认为是高的，IIS 7 / 7.5将开始将请求排队到全局请求队列。这个问题更适用于IIS 7 / 7.5而不是6。
就IIS 6.0而言，没有全局ASP.NET请求队列，但是下面是真的：
1. ASP.NET从IIS IO线程接收请求，并发布“HSE_STATUS_PENDING”到IIS IO线程
2.请求被交给CLR Worker线程
如果请求具有高延迟并且所有线程都被占用(线程计数接近httpRuntime.minFreeThreads)，则请求被发布到应用级请求队列(该队列是根据AppDomain)
4.另外，ASP.NET在接受新请求之前检查排队和当前执行的请求数。如果此数字大于processModel.requestQueueLimit指定的值，则传入请求将被503服务器busy错误拒绝。
解决方法
minFreeThreads: This setting is used by the worker process to queue all the incoming requests if the number of available threads in
the thread pool falls below the value for this setting. This setting
effectively limits the number of requests that can run concurrently to
maxWorkerThreads minFreeThreads. Set minFreeThreads to 88 * # of
cpus. This limits the number of concurrent requests to 12 (assuming
maxWorkerThreads is 100).
编辑：
在@L_403_2@年，托马斯在集成管道中提供了更多的细节和请求处理的例子。请务必阅读答案中的意见，以获得更多解释。
A native callback (in webengine.dll) picks up request on CLR worker
thread,we compare maxConcurrentRequestsPercpu * cpuCount to total active requests. If we’ve exceeded limit,request is inserted in global queue (native code). Otherwise,it will be executed. If it was queued,it will be dequeued when one of the active requests completes.
