2012-03-22 13 views
5

¿Es posible de alguna manera pasar a través de la limitación keepalive de uwsgi? De lo contrario, ¿cuál es la mejor forma de implementación de conexión persistente? Estoy usando NGiNX + uWSGI (Python), y quiero que los clientes tengan actualizaciones asincrónicas desde el servidor.uWSGI keepalive

Respuesta

1

Estás hablando de dos cosas diferentes. Si desea conexiones persistentes de sus clientes a su aplicación, es posible que desee utilizar modos asíncronos (a través de ugreen, gevent ...). De esa manera, podrá mantener miles de conexiones simultáneas. Keepalive es una forma de encaminar múltiples solicitudes a las mismas conexiones, pero esto es bastante inútil para su propósito. En cambio, si se refiere a las conexiones persistentes entre nginx y uWSGI, no hay forma (actualmente) en nginx de alcanzar tal comportamiento. Es posible que desee seguir este billete:

http://projects.unbit.it/uwsgi/ticket/66

se trata de la fastrouter, pero se aplicará en httprouter también. Pero todavía está bajo un gran desarrollo.

1

No, no se puede, porque uwsgi basado en SCGI y cierra los sockets después de cada solicitud. Use FastCGI en su lugar.

1

UWSGI es compatible con keep-alive mediante la opción --http-keepalive si recibe solicitudes a través de http.

/tmp$ cat app.py 
def application(env, start_response): 
    content = b"Hello World" 
    start_response('200 OK', [ 
     ('Content-Type','text/html'), 
     ('Content-Length', str(len(content))), 
    ]) 
    return [content] 

Ejecutar con:

/tmp$ uwsgi --http=:8000 --http-keepalive -w app &> /dev/null 

y podemos ver connect llamadas a través de strace:

~$ strace -econnect wrk -d 10 -t 1 -c 1 http://127.0.0.1:8000 
connect(3, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 
Running 10s test @ http://127.0.0.1:8000 
    1 threads and 1 connections 
    Thread Stats Avg  Stdev  Max +/- Stdev 
    Latency 92.32us 56.14us 2.81ms 97.20% 
    Req/Sec 11.10k 389.34 11.84k 68.32% 
    111505 requests in 10.10s, 7.98MB read 
Requests/sec: 11040.50 
Transfer/sec: 808.63KB 
+++ exited with 0 +++ 

Ver? Solo una conexión.

+0

La opción '-c 1' establece la cantidad de conexiones activas simultáneamente, pero no es necesario funciona en modo keep-alive: https://github.com/wg/wrk/blob/91655b5520b524fc0b802ad12220c9dcd546757e/src/http_parser.c#L2123 . UWSGI agrega 'Connection: close' a cada respuesta. Pero esta herramienta 'uwsgi' podría funcionar en keep-alive por una solución si se conoce el tamaño del contenido: http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html?highlight=keep-alive#http-keep -viva. De todos modos, su aplicación recibe muchas solicitudes por separado. – DenisKolodin

+0

@DenisKolodin > pero no es necesario funciona en modo keep-alive 'wrk' usa http/1.1 así que keep-alive es un modo predeterminado. La misma prueba con strace y 'ab' muestra' connect' en cada solicitud. > Pero esta herramienta uwsgi podría funcionar en keep-alive por una solución si se conoce el tamaño del contenido No es una solución. Es un comportamiento documentado) La mayoría de los frameworks de wsgi configuran Content-Length correctos. – bav

Cuestiones relacionadas