¿Tiempo de inactividad al recargar el demonio mod_wsgi?

Estoy ejecutando una aplicación Django en Apache con mod_wsgi. ¿Habrá algún tiempo de inactividad durante una actualización?

Mod_wsgi se ejecuta en modo daemon, por lo que puedo volver a cargar mi código tocando el archivo de script .wsgi, como se describe en el documento “ReloadingSourceCode”: http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode . Presumiblemente, esa recarga requiere una cantidad de tiempo distinta de cero. ¿Qué sucede si se recibe una solicitud durante la recarga? ¿Apache pondrá en cola la solicitud y luego la completará una vez que el demonio wsgi esté listo?

La documentación incluye la siguiente statement:

Por lo tanto, si está utilizando Django en modo daemon y necesita cambiar su archivo ‘settings.py’, una vez que haya realizado el cambio requerido, toque también el archivo de script que contiene el punto de entrada de la aplicación WSGI. Una vez hecho esto, en la siguiente solicitud, el proceso se reiniciará y su aplicación Django se volverá a cargar.

Para mí, eso sugiere que Apache manejará con gracia todas las solicitudes, pero pensé que iba a pedir para estar seguro. Mi aplicación no es crítica (un poco de tiempo de inactividad no sería desastroso) por lo que la pregunta es principalmente académica.

Gracias.

En el modo daemon, no existe el concepto de un reinicio correcto cuando se toca el archivo de script WSGI para forzar una descarga. Es decir, a diferencia del propio Apache, que iniciará nuevos procesos secundarios del servidor Apache mientras espera que los procesos antiguos terminen con las solicitudes actuales, para los procesos del demonio mod_wsgi, el proceso existente debe finalizar antes de que se inicie uno nuevo.

Las consecuencias de esto son que mod_wsgi no puede esperar indefinidamente a que se completen las solicitudes actuales. Si lo hiciera, entonces existe el riesgo de que si todos los procesos de daemon se atan esperando la finalización de las solicitudes actuales, los clientes verán una demora notable en el manejo.

Sin embargo, en el otro extremo de la escala, el proceso del daemon no puede eliminarse de inmediato, ya que eso podría interrumpir las solicitudes actuales.

Por lo tanto, existe un término medio. El proceso del daemon esperará a que finalicen las solicitudes antes de salir, pero si no se han completado dentro del período de apagado, el proceso del daemon se cerrará a la fuerza y ​​las solicitudes activas se interrumpirán.

El período de este tiempo de espera de apagado predeterminado es de 5 segundos. Se puede anular mediante la opción shutdown-timeout para WSGIDaemonProcess, pero se debe prestar la debida atención a los efectos de cambiarlo.

Por lo tanto, con respecto a este problema específico, si las solicitudes de larga ejecución aún están activas cuando llega la primera solicitud después de haber tocado el archivo de script WSGI, existe el riesgo de que las solicitudes largas activas se interrumpan.

La siguiente cosa notable que puede ver es que incluso si no hay solicitudes de larga ejecución y los procesos se cierran rápidamente, entonces todavía es necesario cargar la aplicación WSGI nuevamente dentro del nuevo proceso. El tiempo que lleva esto se verá como un retraso en el manejo de la solicitud. El tamaño de la demora dependerá del marco y de su aplicación. El peor infractor en cuanto al tiempo de puesta en marcha que conozco es TurboGears. Django es un poco mejor y lo mejor en cuanto a tiempos de inicio rápidos como microestructuras ligeras como Flask.

Tenga en cuenta que no se deben perder las nuevas solicitudes que se reciban mientras se producen estos retrasos de apagado y arranque. Esto se debe a que el zócalo de escucha HTTP tiene una cierta profundidad y las conexiones se ponen en cola en espera de ser aceptadas. Si la cantidad de solicitudes que llegan es grande y esa cola se llena, entonces comenzará a ver errores de conexión rechazada en el navegador.

No, no habrá tiempo de inactividad. Las solicitudes que utilicen el código anterior se completarán y las nuevas solicitudes utilizarán el nuevo código.

Habrá un poco más de carga en el servidor a medida que se cargue el nuevo código, pero a menos que su aplicación sea colosal y sus servidores ya estén casi sobrecargados, esto no se notará.

Esto es como el comando apachectl graceful para Apache como un todo, que le dice que comience una nueva configuración sin tiempo de inactividad.