Solicitudes de larga duración y autodirección en Django

Tengo una configuración con Apache + mod_wsgi ejecutando el código django, y me gustaría agregar una capa de protección en caso de que se deslice una vista no terminada. Algo que mata -de una solicitud que exceda, digamos, 30 segundos sería ideal.Solicitudes de larga duración y autodirección en Django

Para probar Acabo de poner un time.sleep(60) en una vista.

He intentado con la configuración TimeOut 30 en Apache, pero sigo recibiendo curl volviendo después de 60 segundos.

Veo que mod_wsgi ofrece tres valores diferentes de tiempo de espera, pero ninguno de ellos parece aplicarse a una solicitud de larga ejecución.

¿Existe una pieza estándar de middleware de Django para esto o hay un botón que me falta en Apache o mod_wsgi?

Fuente

2011-10-11 Ry4an Brase

En realidad, es realmente difícil terminar un único subproceso de solicitud de Python en una aplicación de subprocesos múltiples. Lo mejor que puede hacer es tomar la decisión de cerrar todo el proceso y reiniciarlo. Debido a que dicha acción interrumpirá las solicitudes simultáneas, como resultado, realmente tendrá que restringirse a una sola configuración de subprocesos.

Incluso entonces, el soporte en mod_wsgi 3.X no es ideal para esto. Hay inactividad-tiempo de espera para el modo daemon, pero en realidad provoca que el proceso se reinicie en dos situaciones. El primero es cuando no hay solicitudes y el proceso está inactivo. El segundo es cuando todos los hilos de solicitud se han bloqueado y el tiempo de espera expira.

En mod_wsgi 4.X (en el tronco del repositorio en este momento), los dos conceptos se han separado y ahora el tiempo de inactividad solo se aplica al proceso completamente inactivo sin solicitudes concurrentes. Se ha agregado un nuevo tiempo de espera bloqueado a un tiempo de espera específico por separado para cuando se bloquea el proceso completo. Es este último que puedes usar.

Si desea obtener más información acerca de la nueva opción, tendrá que ir a la lista de correo mod_wsgi para discutirla.

Fuente

2011-10-11 21:25:59

Gracias. Una cosa que intentamos hacer fue pasar de, digamos 5 procesos con veinte hilos de solicitud cada uno, a 100 procesos con un hilo de solicitud cada uno. La esperanza es que los tiempos de espera de mod_wsgi podrían matar los procesos sin dañar las solicitudes no relacionadas. En la práctica eso no funcionó por razones de memoria del sistema (hubiera esperado más memoria compartida), pero ¿es posible que mod_wsgi pueda matar ese proceso si se dispara el tiempo de inactividad? –

La aplicación se carga después de la horquilla, por lo que no se comparte nada, por lo que la copia al escribir sería un beneficio. El beneficio de la precarga antes del bifurcación en Python no es tanto como la gente pensaría, ya que la ejecución del código manipula los recuentos de referencia, por lo que la copia se realiza en la mayoría de los casos de cualquier manera. –

La opción de tiempo de bloqueo bloqueado en mod_wsgi 4.0 probablemente sea la mejor opción. Todavía puede ejecutar multiproceso y se activará cuando todos los hilos se hayan atascado. Esperar hasta que todos los hilos estén trabajados tampoco es bueno. Entonces también hay una configuración de solicitudes bloqueadas. Si tiene hilos = 15, puede decir bloqueados-solicitudes = 5. De modo que, tan pronto como quede cinco hilos atrapados y llegue al punto en el que el proceso no haya procesado ninguna solicitud, se reiniciará con seguridad. Ser capaz de establecer el umbral de solicitudes bloqueadas le da un margen de seguridad para que el proceso no se empantane. –

Solicitudes de larga duración y autodirección en Django

Respuesta

Cuestiones relacionadas