ASP.NET IIS: ¿cuándo están en cola las solicitudes?

multithreading iis-6

Question

El following artículo de Thomas Marquardt describe cómo IIS maneja las solicitudes ASP.Net, los subprocesos MAX / min CLR worker / Managed IO threads que se pueden configurar para ejecutarse, las diversas colas de solicitudes involucradas y sus tamaños predeterminados.

Ahora, según el artículo, lo siguiente ocurre en IIS 6.0:

1. ASP.NET recoge las solicitudes de un subproceso IIS IO y publica "HSE_STATUS_PENDING" en IIS IO Thread
2. Las solicitudes se entregan a un hilo CLR Worker
3. Si las solicitudes son de alta latencia y todos los subprocesos están ocupados (el recuento de subprocesos se acerca a httpRuntime.minFreeThreads), las solicitudes se publican en la cola de solicitud de nivel de aplicación (esta cola es por dominio de aplicación)
4. También ASP.NET verifica el número de solicitudes que se ejecutan simultáneamente. El artículo establece que "si el número de solicitudes simultáneas de ejecución es demasiado alto", pone en cola las solicitudes entrantes a una cola de solicitudes globales de ASP.NET (esto es por proceso de trabajo) (verifique la actualización 2)

Quiero saber cuál es el "valor de umbral" en qué punto ASP.NET considera que el número de solicitudes que lo ejecutan actualmente es demasiado alto y luego comienza a poner en cola las solicitudes a la cola de solicitudes de ASP.NET global.

Creo que este umbral dependerá de la configuración del número máximo de subprocesos de trabajo, pero puede haber alguna fórmula basada en la cual ASP.NET determinará que el número de solicitudes que se ejecutan simultáneamente es demasiado alto y comienza a poner en cola las solicitudes al ASP.NET cola de solicitud global. ¿Qué podría esta fórmula? o esta configuración es configurable?

Actualizar
Leí nuevamente el artículo y en las secciones de comentarios encontré esto:

1) En IIS 6 y en el modo clásico de IIS 7, cada aplicación (AppDomain) tiene una cola que utiliza para mantener la disponibilidad de subprocesos de trabajo. El número de solicitudes en esta cola aumenta si el número de subprocesos de trabajo disponibles cae por debajo del límite especificado por httpRuntime minFreeThreads. Cuando se excede el límite especificado por httpRuntime appRequestQueueLimit, la solicitud se rechaza con un código de estado 503 y el cliente recibe una HttpException con el mensaje "El servidor está demasiado ocupado". También hay un contador de rendimiento ASP.NET, "Solicitudes en la cola de solicitud", que indica cuántas solicitudes hay en la cola. Sí, el grupo de subprocesos CLR es el expuesto por la clase .NET ThreadPool.

2) El requestQueueLimit tiene un nombre pobre. De hecho, limita la cantidad máxima de solicitudes que ASP.NET puede atender al mismo tiempo. Esto incluye tanto las solicitudes que están en cola como las solicitudes que se están ejecutando. Si el contador de rendimiento "Solicitudes actuales" excede requestQueueLimit, las nuevas solicitudes entrantes se rechazarán con un código de estado 503.

Así que esencialmente requestQueueLimit limita el número de solicitudes que están en cola (supongo que sumará el número de solicitudes puestas en cola de aplicaciones más la cola de solicitudes ASP.Net global más el número de solicitudes que se están ejecutando) y se están ejecutando. Aunque esto no responde a la pregunta original, proporciona información sobre cuándo podríamos recibir un error de servidor ocupado 503 debido a la gran cantidad de solicitudes simultáneas / solicitudes de alta latencia. (Verifique la actualización 2)

Actualización 2 Hubo un error en mi parte en el entendimiento. Había mezclado las descripciones para IIS 6 e IIS 7.
Básicamente, cuando ASP.NET está alojado en IIS 7.5 y 7.0 en modo integrado, las colas de nivel de aplicación ya no están presentes, ASP.NET mantiene una cola de solicitud global.
Por lo tanto, IIS 7 / 7.5 comenzará a poner en cola solicitudes a la cola de solicitud global si el número de solicitudes de ejecución se considera alto. La pregunta se aplica más a IIS 7 / 7.5 que a 6.

En lo que respecta a IIS 6.0 , no hay una cola de solicitud de ASP.NET global, pero la siguiente es verdadera:
1. ASP.NET recoge las solicitudes de un subproceso IIS IO y publica "HSE_STATUS_PENDING" en IIS IO Thread
2. Las solicitudes se entregan a un hilo CLR Worker
3. Si las solicitudes son de alta latencia y todos los subprocesos están ocupados (el recuento de subprocesos se aproxima a httpRuntime.minFreeThreads), las solicitudes se publican en la cola de solicitud de nivel de aplicación (esta cola es por dominio de aplicación)
4. También ASP.NET verifica el número de solicitudes en cola y actualmente en ejecución antes de aceptar una nueva solicitud. Si este número es mayor que el valor especificado por processModel.requestQueueLimit, las solicitudes entrantes se rechazarán con el error de servidor ocupado 503.

Answer 1

Este artículo puede ayudar a entender la configuración un poco mejor.

MinFreeThreads: el proceso de trabajo utiliza esta configuración para poner en cola todas las solicitudes entrantes si la cantidad de subprocesos disponibles en el grupo de subprocesos cae por debajo del valor de esta configuración. Esta configuración limita efectivamente la cantidad de solicitudes que se pueden ejecutar simultáneamente en maxWorkerThreads minFreeThreads. Establezca minFreeThreads en 88 * # de CPU. Esto limita el número de solicitudes concurrentes a 12 (suponiendo que maxWorkerThreads sea 100).

Editar:

En esta publicación SO , Thomas proporciona más detalles y ejemplos de manejo de solicitudes en la canalización integrada. Asegúrese de leer los comentarios en la respuesta para obtener explicaciones adicionales.

Una devolución de llamada nativa (en webengine.dll) capta la solicitud en el hilo de trabajo de CLR, comparamos maxConcurrentRequestsPerCPU * CPUCount con el total de solicitudes activas. Si hemos excedido el límite, la solicitud se inserta en la cola global (código nativo). De lo contrario, se ejecutará. Si se puso en cola, se quitará de la cola cuando se complete una de las solicitudes activas.