2011-01-19 19 views
10

En primer lugar hay una gran visión de conjunto del ciclo de vida de petición HTTP IIS7 y varios ajustes que afectan al rendimiento aquí:IIS7 canalización integrada: Interacción entre maxConcurrentRequestsPerCPU y requestsQueueLimit Opciones

ASP.NET Thread Usage on IIS 7.0 and 6.0

Muy específicamente, sin embargo, en dotNet 4 los valores predeterminados para maxConcurrentRequestsPerCPU y requestsQueueLimit se establecen en 5000. Por ejemplo, equivalente a: (en aspnet.config):

<system.web> 
    <applicationPool 
     maxConcurrentRequestsPerCPU="5000" 
     maxConcurrentThreadsPerCPU="0" 
     requestQueueLimit="5000" /> (** see note below) 
</system.web> 

Me parece que en un multi-CPU del servidor/núcleo del requestQueueLimit aquí siempre se invoca así berfore límite de la 'perCPU'. Por lo tanto, si lo que realmente desea es un máximo de 5000 solicitudes por CPU, entonces esperaría que el requestQueueLimit se aumentara a 5000 * CPUCount o simplemente se desactivara por completo.

¿Mi interpretación es correcta? Si es así, ¿puedo desactivar requestQueueLimit? (configurarlo a cero?). La documentación sobre esta configuración no parece abordar esta pregunta (¿entonces quizás me falta algo o está malinterpretando?)

** nota al margen del artículo anterior: RequestQueueLimit tiene un nombre incorrecto. 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)

+0

Le pedí a Thomas (autor de la publicación que señala) que comente sobre esto. –

Respuesta

12

*** ¿Mi interpretación es correcta?

Sí, si desea ejecutar más de 5000 solicitudes al mismo tiempo, deberá aumentar requestQueueLimit. El requestQueueLimit restringe la cantidad total de solicitudes en el sistema. Debido a su legado, en realidad es el número total de solicitudes en el sistema, y ​​no el número de solicitudes en alguna cola. Su objetivo es evitar que el servidor se caiga debido a la falta de memoria física, memoria virtual, etc. Cuando se alcanza el límite, las solicitudes entrantes recibirán una respuesta rápida de "servidor demasiado ocupado" 503. Por cierto, el contador de rendimiento "ASP.NET \ Requests Current" muestra el número actual de solicitudes en el sistema.

*** ¿Puedo deshabilitar requestQueueLimit? (establézcalo en cero?)

Puede desactivarlo de manera efectiva configurándolo en un valor grande, como 50000. Debe establecer el valor en el archivo aspnet.configSi su servidor puede manejar 50000 solicitudes concurrentes, de ser así, , luego dobla eso. Ponerlo en cero no lo desactivará ... curiosamente, significa que no más de una solicitud se puede ejecutar simultáneamente.

Por cierto, parece que hay un error en v4. Para el modo integrado, solo lee con éxito el valor de requestQueueLimit si está configurado en el archivo aspnet.config como described on MSDN. Por alguna razón, v4 no lo estaba leyendo de machine.config cuando experimenté con él hace un momento.

+0

Gracias por esto. Tal vez podrías aclarar un punto final para mí. Si el total de solicitudes en progreso excede requestQueueLimit, entonces el cliente obtiene un '503 Server Demasiado ocupado' - OK.¿También obtendré un 503 si se excede maxConcurrentRequestsPerCPU/before/requestQueueLimit? Es decir, ¿están controlando el número de solicitudes más o menos en el mismo punto en el ciclo de vida de manejo de solicitudes? Que de lo que he leído es un legado de cómo IIS y ASP.NET han evolucionado. – redcalx

+0

No obtendrá un 503 si se excede maxConcurrentRequestsPerCPU antes de requestQueueLimit. Si se excede maxConcurrentRequestsPerCPU antes de requestQueueLimit, la solicitud se agregará a una cola. Se cancelará en cuanto se complete una de las solicitudes de ejecución. – Thomas

+0

Disculpas pero todavía no está 100% claro ... Recibí la impresión de su blog de que la cola CLR ThreadPool pondría en cola las solicitudes si maxConcurrentRequestsPerCPU * CPUCount era mayor que maxWorkerThreads * CPUCount. Por lo tanto, asumí que ThreadPool Q/was/the global Q se refiere en su blog. Parece que estás diciendo que hay otra cola (herencia de IIS6?) Aparte de ThreadPool Q? – redcalx

2

Es posible que desee verificar el código fuente de la aplicación this. El sintonizador IIS es una aplicación de código abierto que optimiza la configuración de IIS para un mejor rendimiento. Por otro lado, la página this podría ser útil para sus preguntas.

Cuestiones relacionadas