prueba - ¿Un buen servidor web python multiproceso?

servidor web local (11)

Considera reconsiderar tu 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 estado 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.

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 conduciría a la deserialización de los datos provenientes de Memcache, aparte de la sobrecarga adicional de IPC.

Implementé un servidor web simple usando 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?

En su lugar, podría utilizar un caché distribuido al que se pueda acceder desde cada proceso, siendo Memcached el ejemplo que viene a la mente.

Es difícil dar una respuesta definitiva sin saber en qué tipo de sitio estás trabajando y qué tipo de carga estás 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 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.

No multiproceso, pero retorcido podría servir a sus necesidades.

Solo para señalar algo diferente de los sospechosos habituales ...

Hace algunos años, cuando estaba usando Zope 2.x, leí acerca de 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ó.

Uso CherryPy tanto a nivel personal como profesional, 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 mod_proxy y mod_rewrite de Apache para que Apache envíe sus solicitudes a CherryPy de manera transparente.

El sitio web de CherryPy es http://cherrypy.org/

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

Un servidor web de subprocesos WSGI rápido y compatible con HTTP / 1.1. ¡Típicamente, CherryPy toma solo de 1 a 2ms por página!
Compatibilidad con cualquier otro servidor web o adaptador habilitado para WSGI, incluidos Apache, IIS, lighttpd, mod_python, FastCGI, SCGI y mod_wsgi
Fácil de ejecutar múltiples servidores HTTP (por ejemplo, en múltiples puertos) a la vez
Un poderoso sistema de configuración para desarrolladores y desarrolladores por igual
Un sistema de complemento flexible
Herramientas integradas para almacenamiento en caché, codificación, sesiones, autorización, contenido estático y mucho más
Un adaptador nativo mod_python
Un conjunto completo de pruebas
Swappable y personalizable ... todo.
Soporte integrado de perfiles, cobertura y pruebas.

De hecho, 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 Pylons de esta manera:

es similar a Ruby on Rails en que pretende ser muy fácil de implementar aplicaciones web
es el lenguaje de plantillas predeterminado, Mako, es muy agradable trabajar con
usa un sistema de URL de enrutamiento que es muy conveniente
para nosotros el rendimiento no es un problema, por lo que no puedo garantizar que Pylons funcione adecuadamente para sus necesidades
puedes usarlo con Apache & Lighthttpd, aunque no lo he intentado

También ejecutamos una aplicación con Twisted y estamos 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.

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.

Twisted puede servir como un 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

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 utilizando BaseHttpServer y el BaseHttpServer no debería ser difícil.

Además, consulte http://pymotw.com/2/BaseHTTPServer/index.html#module-BaseHTTPServer acerca de la implementación de un servidor multiproceso simple con HTTPServer y ThreadingMixIn