que - ASP.NET Web Garden: ¿cuántos procesos de trabajo necesito?
w3wp.exe windows server 2003 (4)
Las pautas aquí son bastante buenas: http://msdn.microsoft.com/en-us/library/ms998549.aspx
¿Cuál es la mejor práctica para decidir cuántos procesos de trabajo para permitir una aplicación web ASP.NET?
En un servidor que administro, la creación de una nueva AppPool tiene como valor predeterminado 10 procesos de trabajo (como máximo). Otras personas sugieren que la configuración normal es uno.
¿Qué problema resuelven los procesos de múltiples trabajadores y cuáles son las técnicas para decidir cuántos?
Los procesos de trabajo son una forma de segmentar la ejecución de su sitio web a través de múltiples ejecutables. Hace esto por un par de razones, una si uno de los trabajadores es golpeado por problemas de tiempo de ejecución que no derriba a los demás. Por ejemplo, si aparece una solicitud html que causa que el proceso se ejecute en nada, entonces solo las otras solicitudes que están siendo manejadas por ese procesador de un trabajador mueren. Otro ejemplo es que una solicitud podría causar bloqueo contra los otros hilos manejados por el mismo trabajador.
En cuanto a la cantidad que necesite, haga algunas pruebas de carga. Pulse la aplicación con fuerza y vea qué sucede con solo una. Luego agréguele algo más y golpéelo nuevamente. En algún punto, llegará a un punto de saturar verdaderamente la red de las máquinas, el disco, la CPU y el ram. Es entonces cuando sabes que tienes el equilibrio correcto.
Por cierto, puede controlar la cantidad de hilos utilizados por proceso de trabajador a través del archivo machine.config. Creo que la clave es maxWorkerThreads.
Ahora, tenga cuidado, si usa la sesión, el estado de la sesión no se comparte entre los procesos de trabajo. En general, recomiendo evitar la sesión de todos modos, pero es algo a considerar.
Para todos los efectos, podría considerar cada proceso de trabajo como su propio servidor web. Excepto que se están ejecutando en la misma caja.
Otro caso en el que tiene sentido tener muchos procesos de trabajo es si su aplicación contiene bloqueos que impiden su paralelización. El procesamiento de imágenes basado en GDI + es uno de los ejemplos.
Lo encontré cuando traté de encontrar una solución para mi problema .
Pérdidas de memoria
La otra gran ventaja es manejar fugas de memoria. A veces, siempre intenta optimizar su código, pero hay pérdidas de memoria en el marco mismo y en otras bibliotecas de terceros. Notamos que eventualmente nuestra aplicación alcanza una memoria muy alta y comienza a dar excepciones a la memoria.
Así que tuvimos que establecer un límite máximo de memoria virtual en el proceso de trabajo para que parezca 1GB y permitir que se ejecuten varios procesos. Puede establecer el límite virtual máximo incluso para el proceso de trabajador individual, pero esto lleva a un aumento de la velocidad, ya que cuando se recicla el proceso de trabajo, todas las solicitudes son lentas hasta que el proceso de trabajo en tiempo gana buena velocidad. Como nuestra aplicación tiene caché interno (Entity Framework Query Cache, algunos pools de objetos), cada uno de estos aspectos ralentiza el inicio de la aplicación. Aquí es donde el proceso de trabajador individual duele más.
Si hay múltiples procesos de trabajo, solo uno de los procesos en el modo de reciclaje es lento, pero otros mantienen una buena velocidad.