¿Un buen servidor web de python multiproceso?

Question

Estoy buscando un servidor web python que sea multiproceso en lugar de ser multiproceso (como en el caso de mod_python para apache). Quiero que sea multiproceso porque quiero tener un caché de objetos en memoria que será utilizado por varios subprocesos http. Mi servidor web hace muchas cosas costosas y calcula algunas matrices de gran tamaño que deben almacenarse en memoria caché para usarlas en el futuro para evitar el reinicio. Esto no es posible en un entorno de servidor web multiproceso. Tampoco es una buena idea almacenar esta información en Memcache ya que las matrices son grandes y su almacenamiento en Memcache llevaría a la deserialización de los datos provenientes de Memcache, aparte de la sobrecarga adicional de IPC.

Implementé un servidor web simple utilizando BaseHttpServer, ofrece un buen rendimiento pero se bloquea después de unas pocas horas. Necesito un servidor web más madurado. ¿Es posible configurar apache para usar mod_python bajo un modelo de hilo para poder hacer algo de almacenamiento en caché de objetos?

Answer 1

CherryPy. Características, como se detalla en el sitio web:

• Un rápido servidor HTTP agrupado por hilos WSGI, compatible con HTTP/1.1. ¡Típicamente, CherryPy toma solo de 1 a 2ms por página!
• Soporte para cualquier otro servidor web o un adaptador de WSGI habilitados, incluyendo Apache, IIS, lighttpd, mod_python, FastCGI, SCGI y mod_wsgi
• fácil de ejecutar múltiples servidores HTTP (por ejemplo, en varios puertos) a la vez
• Un sistema de configuración de gran alcance para los desarrolladores y los desplegados por igual
• Un sistema de complementos flexible
• herramientas integradas para el almacenamiento en caché, la codificación, las sesiones, la autorización, el contenido estático, y muchos más
adaptador
• Un mod_python nativa
• Un suite de prueba completa
• Swappable y personalizable ... todo.
• Compatibilidad integrada con creación de perfiles, cobertura y pruebas.

Answer 2

No multiproceso, pero twisted podría cubrir sus necesidades.

Answer 3

Quizás tenga un problema con su implementación en Python usando BaseHttpServer. No hay ninguna razón para que se "atasque", y la implementación de un servidor de subprocesos simple usando BaseHttpServer y threading no debería ser difícil.

También, ver http://pymotw.com/2/BaseHTTPServer/index.html#module-BaseHTTPServer sobre la implementación de un simple servidor multi-hilo con HTTPServer y ThreadingMixIn

Answer 4

utilizo CherryPy tanto personal como profesionalmente, y estoy muy contento con él. Incluso hago el tipo de cosas que estás describiendo, como tener cachés de objetos globales, ejecutar otros hilos en segundo plano, etc. Y se integra bien con Apache; simplemente ejecute CherryPy como un servidor independiente vinculado a localhost, luego use Apache's mod_proxy y mod_rewrite para que Apache envíe de forma transparente sus solicitudes a CherryPy.

página web El CherryPy es http://cherrypy.org/

Answer 5

en su lugar podría usar una memoria caché distribuida que se puede acceder desde cada proceso, memcached ser el ejemplo que me viene a la mente.

Answer 6

Considere reconsiderar su diseño. Mantener ese estado en su servidor web es probablemente una mala idea. El proceso múltiple es una forma mucho mejor de lograr la estabilidad.

¿Hay alguna otra manera de compartir estados entre procesos separados? ¿Qué tal un servicio? ¿Base de datos? ¿Índice?

Parece poco probable que mantener una gran cantidad de datos en la memoria y confiar en un único proceso de subprocesos múltiples para atender todas sus solicitudes sea el mejor diseño o arquitectura para su aplicación.

Answer 7

Sólo para señalar algo diferente de los mismos de siempre ... Hace

unos años, cuando estaba usando Zope 2.x que leí sobre Medusa, ya que era el servidor web utilizado para la plataforma. Anunciaron que funciona bien bajo una gran carga y puede proporcionarle la funcionalidad que usted solicitó.

Answer 8

Es difícil dar una respuesta definitiva sin saber en qué tipo de sitio está trabajando y qué tipo de carga está esperando. La segunda función secundaria puede ser un requisito serio o puede no serlo. Si realmente necesita guardar ese último milisegundo, es absolutamente necesario que mantenga sus matrices en la memoria. Sin embargo, como otros han sugerido, es más que probable que no lo haga y que pueda salir adelante con otra cosa. Su patrón de uso de los datos en la matriz puede afectar el tipo de elecciones que realice. Probablemente no necesites acceder a todo el conjunto de datos de la matriz de una sola vez para poder dividir tus datos en fragmentos más pequeños y poner esos fragmentos en la memoria caché en lugar de un gran bulto. Dependiendo de la frecuencia con la que los datos de su matriz deben actualizarse, puede elegir entre memcached, db local (berkley, sqlite, pequeña instalación de MySQL, etc.) o un db remoto. Yo diría que memcached para actualizaciones bastante frecuentes. Un DB local para algo en la frecuencia de cada hora y remota para la frecuencia de todos los días. Una cosa a tener en cuenta también es qué sucede después de fallar un caché. Si 50 clientes repentinamente pierden el caché y todos ellos al mismo tiempo deciden comenzar a regenerar esos matrices caros, su (s) caja (s) se reducirá rápidamente a 8086. Entonces, debes tener en cuenta cómo manejarás eso. Muchos artículos explican cómo recuperarse de fallas en el caché. Espero que esto sea útil.

Answer 9

Twisted puede servir como tal servidor web. Si bien no se multiplicó por sí mismo, hay un contenedor WSGI multiproceso (aún no lanzado) presente en el tronco actual. Puede consultar el repositorio SVN y luego ejecutar:

twistd web --wsgi=your.wsgi.application 

Answer 10

En realidad tuve el mismo problema recientemente. A saber: escribimos un servidor simple utilizando BaseHTTPServer y descubrimos que el hecho de que no es multihilo era un gran inconveniente.

Mi solución fue portar el servidor a Pylons (http://pylonshq.com/). El puerto fue bastante fácil y un beneficio fue que es muy fácil crear una GUI usando Pylons, así que pude lanzar una página de estado además de lo que básicamente es un proceso de daemon.

Yo resumiría los pilones de esta manera:

• es similar a Ruby on Rails, ya que apunta a ser muy fácil de implementar aplicaciones web
• está lenguaje de plantillas por defecto, Mako, es muy agradable trabajar con
• que utiliza un sistema de URLs que es muy conveniente
• para nosotros enrutamiento rendimiento no es un problema, por lo que no puede garantizar que los pilones llevaría a cabo de manera adecuada para sus necesidades
• que pueda utilizarlo con Apache & LightHTTPD, aunque no he intentado esto

También llevamos a cabo una aplicación con trenzado y están contentos con ella. Twisted tiene un buen rendimiento, pero considero que el modelo de programación de un solo subproceso/diferir a la secuencia de Twisted es bastante complicado. Tiene muchas ventajas, pero no sería mi elección para una aplicación simple.

Buena suerte.

Answer 11

web.py me ha hecho feliz en el pasado. Considera echarle un vistazo.

Pero parece que un rediseño arquitectónico podría ser la solución adecuada, aunque más costosa.