Pregunta

Estoy buscando un servidor web de Python que sea multiproceso en lugar de multiproceso (como en el caso de mod_python para apache). Quiero que sea multiproceso porque quiero tener una memoria caché de objetos en memoria que será utilizada por varios hilos http. Mi servidor web hace un montón de cosas caras y calcula algunas matrices grandes que deben almacenarse en la memoria caché para un uso futuro para evitar volver a calcularlas. Esto no es posible en un entorno de servidor web multiproceso. Almacenar esta información en memcache tampoco es una buena idea, ya que los arreglos son grandes y almacenarlos 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 usando BaseHttpServer, da un buen rendimiento pero se bloquea después de unas pocas horas. Necesito un servidor web más maduro. ¿Es posible configurar apache para usar mod_python en un modelo de subproceso para que pueda hacer algo de almacenamiento en caché de objetos?

¿Fue útil?

Solución

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

  • Un servidor web agrupado de subprocesos WSGI rápido, que cumple con HTTP / 1.1. ¡Por lo general, CherryPy toma solo 1-2ms por página!
  • Soporte para cualquier otro servidor web o adaptador habilitado para WSGI, 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 potente sistema de configuración para desarrolladores y desarrolladores por igual
  • Un sistema de complementos flexible
  • Herramientas integradas para almacenamiento en caché, codificación, sesiones, autorización, contenido estático y mucho más
  • Un adaptador nativo de mod_python
  • Un conjunto de pruebas completo
  • Intercambiable y personalizable ... todo.
  • Soporte integrado de perfiles, cobertura y pruebas.

Otros consejos

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 estabilidad.

¿Hay otra manera de compartir el estado entre procesos separados? ¿Qué pasa con un servicio? ¿Base de datos? ¿Índice?

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

Twisted puede servir como tal servidor web. Si bien no es multihilo en sí, hay un contenedor WSGI multiproceso (aún no publicado) presente en el tronco actual. Puede revisar el repositorio de SVN y luego ejecutar:

twistd web --wsgi=your.wsgi.application

Es difícil dar una respuesta definitiva sin saber en qué tipo de sitio está trabajando y qué tipo de carga está esperando. Sub segundo rendimiento puede ser un requisito serio o no puede. Si realmente necesita guardar ese último milisegundo, entonces absolutamente necesita mantener sus arreglos en la memoria. Sin embargo, como otros han sugerido, es más que probable que usted no lo haga y podría salir adelante con otra cosa. Su patrón de uso de los datos en la matriz puede afectar los tipos de elecciones que realiza. Es probable que no necesite acceder a todo el conjunto de datos de la matriz de una vez, por lo que podría dividir sus datos en trozos más pequeños y colocarlos en el caché en lugar del único gran bulto. Dependiendo de la frecuencia con la que se actualicen los datos de su matriz, puede elegir entre memcached, db local (berkley, sqlite, pequeña instalación de mysql, etc.) o un db remoto. Yo diría memcached para actualizaciones bastante frecuentes. Un db local para algo en la frecuencia de cada hora y remoto para la frecuencia de cada día. Una cosa a considerar también es lo que sucede después de una falta de caché. Si de repente, 50 clientes obtienen una falla de caché y todos al mismo tiempo deciden comenzar a regenerar esos costosos arreglos, sus cajas se reducirán rápidamente a 8086. Así que hay que tener en cuenta cómo manejará eso. Muchos artículos explican cómo recuperarse de las fallas de caché. Espero que esto sea útil.

No es multiproceso, pero twisted puede satisfacer tus necesidades.

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

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

Pero suena como si un rediseño arquitectónico pudiera ser la solución adecuada, aunque más costosa.

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

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

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

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

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

Mi solución fue trasladar el servidor a Pylons ( http://pylonshq.com/ ). El puerto fue bastante fácil y uno de los beneficios fue que es muy fácil crear una GUI usando pilones, por lo que pude lanzar una página de estado sobre lo que es básicamente un proceso de daemon.

Yo resumiría los pilones de esta manera:

  • es similar a Ruby on Rails, ya que pretende ser muy fácil de implementar aplicaciones web
  • es un lenguaje de plantillas predeterminado, Mako, es muy agradable trabajar con
  • utiliza un sistema de enrutamiento de URL que es muy conveniente
  • para nosotros, el rendimiento no es un problema, por lo que no puedo garantizar que Pylons se desempeñe adecuadamente para sus necesidades
  • puedes usarlo con Apache & amp; 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 me parece bastante complicado el modelo de programación de subproceso único / retardo a subproceso de Twisted. Tiene muchas ventajas, pero no sería mi elección para una aplicación simple.

Buena suerte.

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

Hace algunos años, mientras estaba usando Zope 2.x leí sobre Medusa ya que fue el servidor web utilizado para la plataforma. Lo anunciaron para que funcione bien bajo una carga pesada y puede proporcionarle la funcionalidad que solicitó.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top