¿Qué ocurre con otros usuarios si el proceso de trabajo de .NET se estrella?

Question

Mi conocimiento de cómo los procesos son manejados por el proceso de trabajo de ASP.Net es lamentablemente inadecuada. Estoy esperando que algunos de los expertos por ahí me puede rellenar.

Si colapso del proceso de trabajo con un System.OutOfMemoryException, lo que sería la experiencia del usuario sea para otros usuarios que estaban siendo atendidos por el mismo proceso? Conseguirían una pantalla en blanco? 503 error?

Voy a intentar probar este escenario con algunas otras personas en nuestro laboratorio, pero pensé que iba a flotar esta ahí fuera. Voy a actualizar con nuestros resultados.

Actualizar : Nuestros resultados variaron. Si nos induce artificialmente una excepción OOM (por ejemplo, mediante la carga de archivos PDF más y más grandes en la memoria), otros hilos siendo atendidos por dicho proceso de trabajo se "cuelgue" temporalmente y luego completa, mientras que otros aparentemente no regresarían jamás. Gracias por sus respuestas.

Answer 1

W3WP.exe es el proceso

IIS se ejecuta todas las aplicaciones web en un proceso de trabajo genérico - w3wp.exe. Si usted escribe en ASP.NET, o ISAPI, o algún otro marco, el proceso que sirve a la solicitud web es w3wp.exe. En el caso ASP.NET, cargas w3wp.exe las DLL y los servicios de las solicitudes a través de ellos compilados JIT-ASP.NET. En otros casos, funciona de manera diferente. Pero el punto clave es, w3wp.exe es el proceso. Este modelo se inició en IIS6.0 y continúa en IIS7.0.

fallos inesperados

Si el W3WP.exe falla inesperadamente, por cualquier razón, todas las transacciones se manejando es probable que obtener 500 errores (Error del servidor). IIS se iniciará un nuevo proceso de trabajo en su lugar ( MS llama a esto "Vigilancia de la salud" ), lo que significa la aplicación web seguirá funcionando. Los usuarios que no tienen una petición que es servido por el proceso de fallar en el momento del fallo, no serán conscientes de nada de esto.

  

El error HTTP 500 que un cliente recibe en este caso será indistinguible de un error 500 que el cliente recibe en el caso de un error de aplicación, digamos que una excepción no capturada en el código de aplicación ASPNET.

Para aquellas solicitudes que estaban en el proceso en su defecto, no hay forma de recuperarlos. Que se traducirá en 500 errores en el navegador. A 503 Server Busy resultados de IIS negarse activamente la conexión debido a un umbral en el número de conexiones. A 503 no es resultado de un fallo de aplicación, por lo que no debe esperar ver 503 para las transacciones en vuelo en el accidente y fuera de la memoria en escenarios. En un sistema con mucha carga, puede ver 503 de que el proceso de caída y reinicio ocurre, como un efecto secundario. Si esto es realmente lo que se está viendo, es necesario un mayor margen de seguridad para manejar la carga en la condición de un solo error.

La Cola de solicitudes

IIS tiene un enfoque hand-off para solicitudes . A medida que llegan a la capa de red (HTTP.sys), se colocan en una cola, para ser recogido por un proceso de trabajo. Cualquier solicitud que esperan en la cola de IIS para ser manejados por un WP continuará afectado, aunque podría ver un ligero incremento transitorio en la latencia (tiempo de servicio) debido a la contención de recursos, ya que un proceso menos se está ejecutando en el servidor. tiempo de espera en la cola es en general muy muy corto, en un sistema que está configurado correctamente.

Es cuando esta cola está llena que se pueden ver 503 errores.

reinicio automático de W3WP.exe

IIS tiene un auto-reinicio (o "niñera") instalación, a través del cual se reinicia procesos de trabajo después de que hayan superado los umbrales configurado , como el tamaño de la memoria, el número de solicitudes o de tiempo de ejecución. En todos los casos, IIS poner en modo inactivo y procesos de trabajo de reinicio cuando se alcanza el umbral configurado. Estos se reinicia proactivas normalmente no dan lugar a ninguna interrupción de las solicitudes. Cuando IIS decide que un reinicio de un proceso de trabajo es necesario, se evita cualquier nueva solicitud de llegar a esa WP-a-de estar inmovilizada. solicitudes existentes se drenan : cualquier transacción en vuelo en el que WP se les permite completar con normalidad. Cuando todas las solicitudes en el WP completa, entonces las matrices WP y IIS se inicia una nueva en su lugar. Este nuevo proceso se inicia inmediatamente después de recoger nuevas solicitudes de la cola de distribución. Todo esto es transparente para los usuarios o navegadores.

Yo digo normalmente porque es posible que el pro trabajadorceso se ha convertido realmente enferma al mismo tiempo que se ha alcanzado el umbral. En ese caso el w3wp.exe pueden no responder a IIS dentro la configuración de "inmovilización" tiempo de espera , y por lo tanto tiene IIS para matar el tiempo del proceso a pesar de que no se ha informado de que todas sus peticiones en vuelo hayan completado. Esto debería ser excesivamente rara, porque se trata de dos condiciones excepcionales distintas, pero sucede. En este caso, las solicitudes durante el vuelo, una vez más, obtener 500 errores.

jardines de la web

También - IIS permite que varios procesos de trabajo en un único servidor. MS llamadas esto un "jardín web", un juego de palabras de "granja de servidores web". Si usted tiene un jardín web configurado, entonces las transacciones que se sirve por instancias distintas de la w3wp.exe no uno, continuará afectado. presume "no afectada" sin embargo, que se localiza el error fuera de la memoria, y no un problema de todo el sistema.

Bottom Line

La conclusión es que no hay sustituto para sus propias pruebas. Las opciones de configuración son bastante amplio - de los umbrales de reinicio para jardines web y así sucesivamente. También los modos de fallo tienden a ser bastante complejo y variado, si se trata de la memoria, tiempo de espera, demasiado ocupado, y así sucesivamente. Usted quiere entender qué esperar.

PD: Este Q & A pertenece realmente en serverfault.com !!

---

referencias:
http: // blogs. iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

Answer 2

Un nuevo subproceso de trabajo se iniciará y el usuario no sabría nada sucedió. A menos que se apaga por completo a través de una rápida falla ( http: // technet.microsoft.com/en-us/library/cc779127(WS.10).aspx )

Answer 3

Si se trata de una situación de falta de memoria, IIS por lo general sólo se recicla el grupo de aplicación.

Answer 4

Como dicen las otras respuestas, en la mayoría de los casos todo lo que sólo se reinicia, y la mayoría de los usuarios que no tienen una solicitud pendiente en el momento no notará mucho más que un retraso.

Sin embargo, si la aplicación utiliza variables de sesión con estado de sesión en proceso, todas las variables de sesión para todos los usuarios se perderá cuando se reinicia el grupo de aplicaciones. Esto puede o no puede tener un efecto negativo sobre los usuarios, dependiendo de lo que está haciendo con las variables de sesión. Esto se puede evitar cambiando a StateServer o SQL Server de almacenamiento de sesión.