deploy - Propagar http abort/close de nginx a uwsgi/Django

postgres django nginx

Question

Tengo una aplicación web de la aplicación Django, y me preguntaba si era posible hacer que nginx propague el aborto / cerca de uwsgi / Django.

Básicamente, sé que nginx es consciente de la anulación / cierre prematuro porque de manera predeterminada es uwsgi_ignore_client_abort en "off", y usted obtiene errores nginx 499 en sus registros nginx cuando las solicitudes se cancelan / cierran antes de enviar la respuesta. Una vez que uwsgi termina de procesar la solicitud, arroja un "Error de E / S" cuando devuelve la respuesta a nginx.

Activar uwsgi_ignore_client_abort en "on" simplemente hace que nginx no sea consciente de abortar / cerrar, y elimina los "Errores de E / S" de uwsgi porque uwsgi todavía puede escribir en nginx.

Mi caso de uso es que tengo una aplicación donde la página de personas a través de algunos resultados de ajax muy rápidamente, por lo tanto, si la página rápida abortaré la solicitud de ajax pendiente para la página que omitieron, esto mantiene al cliente limpio y eficiente. Pero esto no hace nada por el lado del servidor (uwsgi / Django) porque todavía tienen que procesar cada solicitud individual, incluso si nada está esperando la respuesta.

Ahora, obviamente, puede haber ciertas páginas, en las que no deseo que la solicitud se cancele prematuramente por ningún motivo. Pero utilizo apio para solicitudes de larga duración que pueden caer en esa categoría.

Entonces, ¿es esto posible? uwsgi''s configuración uwsgi''s uwsgi me hace pensar que está en algún nivel ... simplemente no puedo averiguar cómo hacerlo.

Answer 1

Ahora, obviamente, puede haber ciertas páginas, en las que no deseo que la solicitud se cancele prematuramente por ningún motivo.

Este es precisamente el problema detrás de tomar esto de una manera u otra.

• Obviamente, es posible que no desee seguir gastando recursos del sistema en el procesamiento de una conexión que desde entonces ha sido abortada, por ejemplo, una operación de búsqueda costosa.

• Pero quizás la conexión fue lo suficientemente importante como para que aún deba procesarse, incluso si el cliente se ha desconectado.

  • Por ejemplo, la misma operación costosa de búsqueda, pero que en realidad no es específica del cliente, y será guardada en caché por nginx para todos los clientes posteriores, también.

  • O tal vez una operación que modifique el estado de su aplicación, ¡claramente no querría que su aplicación tenga un estado inconsistente!

Como se mencionó, el problema es con uWSGI, no con NGINX. Sin embargo, no puede hacer que uWSGI decida automáticamente cuál fue su intención, sin que usted mismo lo revele a uWSGI.

¿Y cómo exactamente revelarás tu intención en tu código? Una gran cantidad de lenguajes de programación no son realmente compatibles con los modelos de programación multiproceso y / o asíncronos, lo que hace que sea completamente no trivial cancelar las operaciones.

Como tal, no hay solución mágica aquí. Incluso los lenguajes de programación amigables con la concurrencia como Golang están teniendo problemas con el context WithCancel ; es posible que tenga que pasarlo por WithCancel en cada llamada de función que pueda bloquear, lo que hace que el código sea muy feo.

¿Ya estás haciendo pasar el contexto anterior en Django? Si no, la solución es fea pero muy simple: en cualquier momento que pueda abortar claramente la solicitud, verifique si el cliente todavía está conectado con uwsgi.is_connected(uwsgi.connection_fd()) :

• http://lists.unbit.it/pipermail/uwsgi/2013-February/005362.html

Answer 2

Mi caso de uso es que tengo una aplicación donde la página de personas a través de algunos resultados de ajax muy rápidamente, por lo tanto, si la página rápida abortaré la solicitud de ajax pendiente para la página que omitieron, esto mantiene al cliente limpio y eficiente.

El aborto de una solicitud AJAX en el lado del cliente se realiza a través de XMLHttpRequest.abort() . Si la solicitud aún no se ha enviado cuando se llama a abort() , la solicitud no saldrá. Pero si la solicitud ha sido enviada, el servidor no sabrá que la solicitud ha sido cancelada. La conexión no se cerrará, no se enviará ningún mensaje al servidor, nada. Si desea que el servidor sepa que una solicitud ya no es necesaria, básicamente debe encontrar una manera de identificar las solicitudes para que cuando realice la solicitud inicial obtenga un identificador para la misma. Luego, a través de otra solicitud AJAX, podría decirle al servidor que una solicitud anterior debe cancelarse. (Si busca preguntas sobre abort() como esta y busca "servidor", encontrará explicaciones que dicen lo mismo).

Tenga en cuenta que uwsgi_ignore_client_abort es algo que se ocupa de los cierres de conexión en el nivel TCP . Eso es una cosa diferente de abortar una solicitud AJAX. En general, no hay ninguna acción que pueda tomar en JavaScript que implique cerrar una conexión TCP. El navegador optimiza la creación y destrucción de conexiones para satisfacer sus necesidades. Justo ahora, hice esto:

1. Utilicé lsof para comprobar si algún proceso tenía una conexión con example.com . No había ninguno. ( lsof es una utilidad * nix que permite listar archivos abiertos. Las conexiones de red son "archivos" en * nix.)

2. Abrí una página para example.com en Chrome. lsof mostró la conexión y el proceso que lo abrió.

3. Luego cerré la página.

4. Encuesté con lsof para ver si la conexión que identifiqué anteriormente todavía estaba abierta. Permaneció abierto durante aproximadamente un minuto después de que cerré la página, aunque no había ninguna necesidad real de mantener la conexión abierta.

Y no hay una cantidad de problemas con la configuración de uswgi que le permita conocer las anulaciones realizadas a través de XMLHttpRequest.abort()

El escenario de caso de uso que proporcionó fue uno en el que los usuarios estaban paginando rápidamente con algunos resultados. Puedo ver dos posibilidades para la descripción dada en la pregunta:

1. El usuario espera una actualización antes de seguir paginando. Por ejemplo, Alice está buscando en una lista de nombres de usuarios ordenados alfabéticamente para el usuario "Zeno" y cada vez que se muestra una nueva página, ve que el nombre no está allí y las páginas están abajo. En este caso, no hay nada que anular porque la acción del usuario depende de que la solicitud se haya manejado primero . (El usuario tiene que ver la nueva página antes de tomar una decisión.)

2. El usuario solo baja las páginas sin esperar una actualización. Alice nuevamente está buscando a "Zeno", pero ella cree que estará en la última página, así que haga clic, haga clic, haga clic en ella. En este caso, puede rebotar las solicitudes realizadas al servidor. Luego, al presionar el botón de la página siguiente, incremente el número de la página que debe mostrarse al usuario, pero no envíe la solicitud de inmediato. En su lugar, espera un pequeño retraso después de que el usuario deja de hacer clic en el botón para enviar la solicitud con el número de página final y así realizar una solicitud en lugar de una docena. Here es un ejemplo de un rebote realizado para una búsqueda de DataTables.