modpython vs modwsgi

[lasizoillo]

El día 22 de octubre de 2009 13:42, Chema Cortes <pych3m4 en gmail.com> escribió:
> El día 22 de octubre de 2009 10:04, FreeMEM
> <francisco.antonio en tapiasbravo.com> escribió:
>
>> Yo me he metido en el mundo de "python web" hará unos tres meses, con
>> modpython y estoy encantado, sin embargo alguien dijo en esta lista que
>> la solución modpython es más lenta y pesada que la modwsgi. La pregunta
>> es ¿cuánto más lento o rápido?.
>
> Los chicos de #python.web explican sus razones para desaconsejar el
> uso de mod_python:
>
> <http://wiki.python.org/moin/PoundPythonWeb>
> <http://wiki.python.org/moin/PoundPythonWeb/mod_python>
>
>
> No tengo información de rendimientos en alta demanda. Sospecho, por la
> referencia a slicehost que haces, que estás interesado en que funcione
> tu aplicación web en un sistema virtual. En estos sistemas es casi más
> importante el gasto de memoria que el rendimiento, por lo que una
> solución basada en nginx+mod_wsgi es, sin duda, la mejor opción para
> mantener un alto número de conexiones sin excederse en el gasto de
> memoria.
>
> http://wiki.nginx.org/NginxNgxWSGIModule

Yo no sería tan valiente haciendo eso. Sobre todo si leemos la siguiente linea:
If a module blocks, the entire application will blocks.

Eso quiere decir que si haces una llamada sincrona al servidor de
BB.DD. (lo típico), el resto de las peticiones se quedarán esperando.
Hay posibles parches (no me atrevo a decir soluciones) para este tema
como los proporcionados por la gente de eventlet:
http://eventlet.net/doc/modules/db_pool.html

El modulo ese puede ser una buena forma de conseguir un rendimiento
brutal, pero también una manera sencilla de tener un nginx bloqueado.
Se pueden levantar varios procesos de nginx, pero es mejor levantar
varios procesos fastcgi o http y que el nginx haga de proxy. El
funcionamiento normal de nginx es el siguiente:
* Lee la petición entera. El backend no es molestado mientras se está
subiendo un fichero a velocidad lenta como en otros sistemas.
* Reenvia al backend la petición una vez leida.
* Va reenviando al backend los datos del backend hacia el cliente a
través de un buffer.
* Cuando termina el backend libera esa conexión para que esté
accesible para otra petición de nginx
* Se encarga de enviar el los datos del buffer al cliente, mientras
tiene liberado el backend.

Con el módulo wsgi de apache no te disparas al pie de esa forma, pero
te pueden pasar otras cosas. Ejemplo: Tu aplicación está preparada
para que el GIL salve los posibles problemas de concurrencia, pero el
modulo de apache levanta varias instancias de python en diferentes
procesos. Solución: Hacer código que permita multiproceso. Normalmente
los apis para manejar sessiones que guardan datos en ficheros ya se
preocupan de bloqueos y demás, pero si estamos hablando de hacer las
cosas desde 0 sin frameworks.... más vale saber lo que se hace por
detrás.

Un saludo:

Javi
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes