Thomas Marquardt撰写的following文章描述了IIS如何处理ASP.Net请求，可配置为运行的最大/最小CLR工作线程/托管IO线程，涉及的各种请求队列及其默认大小。
现在根据文章，IIS 6.0中会出现以下情况：
我想知道什么是“阈值”，此时ASP.NET认为当前执行它的请求数太高，然后开始将请求排队到全局ASP.NET请求队列？
我认为这个阈值将取决于最大工作线程数的配置，但可能有一些公式基于哪个ASP.NET将确定并发执行请求的数量太高并开始将请求排队到ASP.NET全局请求队列。这个公式可能是什么？或者此设置是否可配置？
<小时/> 的更新
1）在IIS 6和IIS 7经典模式下，每个应用程序（AppDomain） 有一个队列，用于维护工作人员的可用性 线程。如果数字，此队列中的请求数会增加 可用的工作线程数低于指定的限制 httpRuntime minFreeThreads。当指定的限制时 超过httpRuntime appRequestQueueLimit，请求是 被503状态代码拒绝，客户端收到 HttpException，消息“Server too busy”。还有一个 ASP.NET性能计数器，“应用程序队列中的请求”，即 表示队列中有多少请求。是的，CLR线程 pool是.NET ThreadPool类公开的那个。
2）requestQueueLimit命名不佳。它实际上限制了 ASP.NET可以处理的最大请求数 同时。这包括排队的请求和 正在执行的请求。如果“请求当前”表现 计数器超过requestQueueLimit，新的传入请求将是 被503状态代码拒绝。
<击> 因此，基本上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工作者线程
3.如果请求具有高延迟并且所有线程都被占用（线程计数接近httpRuntime.minFreeThreads），则请求将发布到应用程序级别请求队列（此队列是每个AppDomain）
4. ASP.NET还会在接受新请求之前检查排队和当前正在执行的请求数。如果此数字大于processModel.requestQueueLimit指定的值，则将拒绝传入的请求，并显示503服务器忙。
答案 0 :(得分：4)
This article可能有助于更好地理解设置。
minFreeThreads：如果可用线程数在，则工作进程使用此设置对所有传入请求进行排队 线程池低于此设置的值。这个设置 有效地限制了可以同时运行的请求数 maxWorkerThreads minFreeThreads。将minFreeThreads设置为88 *＃ 的CPU。这将并发请求的数量限制为12（假设 maxWorkerThreads是100）。
修改
在此SO post中，Thomas提供了有关集成管道中请求处理的更多详细信息和示例。请务必阅读有关答案的评论，以获得更多解释。
本机回调（在webengine.dll中）接收CLR工作者的请求 我们将 maxConcurrentRequestsPerCPU * CPUCount 与总计进行比较 活跃的请求。如果我们超出限制，请插入请求 全局队列（本机代码）。否则，它将被执行。如果它是 排队后，当其中一个活动请求完成时，它将被出列。