Tiempo de inactividad al volver a cargar mod_wsgi daemon?

Question

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 una solicitud entra durante la recarga? ¿Apache pondrá en cola la solicitud y luego la completará una vez que el daemon wsgi esté listo?

La documentación incluye la siguiente declaración:

Por lo tanto, si usted está usando Django en modo demonio y tenía que cambiar su archivo 'settings.py', una vez que haya realizado el cambio es necesario, también tocar 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 se volverá a cargar la aplicación Django.

Para mí, eso sugiere que Apache manejará con gracia cada solicitud, pero pensé que podría preguntar para estar seguro. Mi aplicación no es crítica (un pequeño tiempo de inactividad no sería desastroso) por lo que la pregunta es principalmente académica.

Gracias.

Answer 1

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

Las consecuencias de esto son que mod_wsgi no puede esperar indefinidamente para que se completen las solicitudes actuales. Si así fuera, entonces existe el riesgo de que si todos los procesos del daemon están atados esperando que finalicen las solicitudes actuales, los clientes verán un retraso notable en el manejo.

En el otro extremo de la escala, sin embargo, el proceso del daemon no se puede eliminar de inmediato ya que eso podría causar la interrupción de las solicitudes actuales.

Por lo tanto, existe un término medio. El proceso de daemon esperará a que las solicitudes finalicen 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 tiempo de espera de apagado predeterminado es de 5 segundos. Se puede anular utilizando la opción shutdown-timeout para la directiva WSGIDaemonProcess, pero se deben tener en cuenta los efectos de cambiarla.

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

La próxima cosa notable que puede ver es que incluso si no hay solicitudes de larga ejecución y el cierre de procesos con prontitud, entonces todavía es necesario cargar la aplicación WSGI nuevamente dentro del nuevo proceso. El tiempo que esto tome se verá como un retraso en el manejo de la solicitud. Qué tan grande sea ese retraso dependerá del marco y su aplicación. El peor ofensor en cuanto al tiempo necesario para comenzar, que yo sepa, es TurboGears. Django es algo mejor y lo mejor en cuanto a tiempos de puesta en marcha rápidos son los micro frameworks livianos como Flask.

Tenga en cuenta que no debe perderse ninguna solicitud nueva que se produzca mientras se producen estas demoras de apagado e inicio. Esto se debe a que el conector de escucha HTTP tiene una cierta profundidad y cola de conexiones en espera de ser aceptado. Si el número de solicitudes que llegan es enorme y la cola se llena, entonces comenzará a ver errores de conexión rechazados en el navegador.

Answer 2

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

Habrá un poco más de carga en el servidor a medida que se carga 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 en su conjunto, que le indica que inicie una nueva configuración sin tiempo de inactividad.