Pregunta

Estoy a punto de implementar un sitio de tamaño mediano impulsado por Django.Tengo un servidor Ubuntu dedicado.

Estoy realmente confundido sobre qué software de servidor usar.Entonces pensé para mis adentros:¿Por qué no preguntarle a Stackoverflow?

Lo que estoy buscando es:

  • Fácil de configurar
  • Rápido y fácil de usar
  • Puede servir archivos multimedia
  • Capaz de servir múltiples sitios djangos en el mismo servidor
  • Preferiría no instalar PHP ni cualquier otra cosa que consuma recursos y que no pueda utilizar.

He oído hablar de mod_wsgi y mod_python en Apache, nginx y lighty.¿Cuáles son los pros y los contras de estos? ¿Me he perdido a alguien?

@barry:De alguna manera siento que Apache está demasiado hinchado para mí.¿Qué pasa con las alternativas?

@BrianLy:Ok, revisaré mod_wsgi un poco más.Pero, ¿por qué necesito Apache si entrego archivos estáticos con Lighty?También logré servir la aplicación Django con Lighty.¿Es eso malo de alguna manera?Perdón por ser tan estúpido :-)

ACTUALIZAR:¿Qué pasa con lighty y nginx? ¿Cuáles son los casos de uso en los que son la elección perfecta?

¿Fue útil?

Solución

Como estaba buscando respuestas más profundas, decidí investigar el tema en profundidad yo mismo.Por favor, avíseme si he entendido mal algo.

Una recomendación general es utilizar un servidor web independiente para manejar los medios.Por separado, me refiero a un servidor web que no ejecuta Django.Este servidor puede ser por ejemplo:

  • Lighttpd (Lighty)
  • Nginx (EngineX)
  • O algún otro servidor liviano

Entonces, para Django, puedes tomar diferentes caminos.Tu también puedes:

  • Servir a Django a través de apache y:

    • mod_python

      Esta es la forma estable y recomendada/bien documentada.Contras:utiliza mucha memoria.

    • mod_wsgi

      Por lo que tengo entendido, mod_wsgi es una alternativa más nueva.Parece ser más rápido y más fácil con los recursos.

    • mod_fastcgi

      Cuando usas FastCGI, estás delegando el servicio de Django a otro proceso.Dado que mod_python incluye un intérprete de Python en cada solicitud, utiliza mucha memoria.Esta es una manera de evitar ese problema.También existen algunas preocupaciones de seguridad.

      Lo que debe hacer es iniciar su servidor Django FastCGI en un proceso separado y luego configurar Apache mediante reescrituras para llamar a este proceso cuando sea necesario.

O tu puedes:

  • Servir a Django sin usar apache pero con otro servidor que soporte FastCGI de forma nativa:

    (La documentación menciona que puede hacer esto si no tiene ninguna necesidad específica de Apache.Supongo que la razón debe ser para ahorrar memoria).

    • Lighttpd

    Este es el servidor que ejecuta Youtube.Parece rápido y fácil de usar, sin embargo, he visto informes sobre pérdidas de memoria.

    • nginx

    He visto puntos de referencia que afirman que este servidor es incluso más rápido que lighttpd.Aunque está documentado principalmente en ruso.

Otra cosa, debido a las limitaciones de Python, su servidor debería ejecutarse en modo bifurcado, no en modo subproceso.

Esta es mi investigación actual, pero quiero más opiniones y experiencias.

Otros consejos

Estoy usando Cherokee.

De acuerdo a sus puntos de referencia (un grano de sal con ellos), maneja la carga mejor que Lighttpd y nginx...Pero no es por eso que lo uso.

Lo uso porque si escribes cherokee-admin, inicia un nuevo servidor en el que puedes iniciar sesión (con una contraseña de un solo uso) y configurar todo el servidor a través de un webmin bellamente hecho.Esa es una característica excelente.Ya me ha ahorrado un lote de tiempo.¡Y le está ahorrando muchos recursos a mi servidor!

En cuanto a Django, lo estoy ejecutando como un proceso SCGI con subprocesos.Funciona bien.Cherokee también puede mantenerlo funcionando.De nuevo, una característica muy buena.

La versión actual del repositorio de Ubuntu es muy antigua, por lo que te recomiendo que uses su PPA.Buena suerte.

Como dijo @Barry, la documentación usa mod_python.No he usado Ubuntu como servidor, pero tuve una buena experiencia con mod_wsgi en Solaris.Puedes encontrar documentación para mod_wsgi y Django sobre el mod_wsgi sitio.

Una revisión rápida de sus requisitos:

  • Fácil de configurar He encontrado que Apache 2.2 es bastante fácil de construir e instalar.
  • Rápido y fácil de usar Yo diría que esto depende de su uso y tráfico.* Es posible que no quieras servir todos los archivos usando Apache y usar TPD ligero (lighty) para servidores de archivos estáticos.
  • Puede servir archivos multimedia Supongo que te refieres a imágenes, archivos flash.Apache puede hacer esto.
  • Varios sitios en el mismo servidor Alojamiento de servidor virtual en Apache.
  • Prefiero no instalar otras extensiones. Comente todo lo que no desee en la configuración de Apache.

La forma oficialmente recomendada de implementar un proyecto Django es usar mod_python con Apache.Esto se describe en la documentación. La principal ventaja de esto es que es la forma de implementación mejor documentada, más compatible y más común.La desventaja es que probablemente no sea el más rápido.

Creo que la mejor configuración no es tan conocida.Pero aquí está:

  1. Utilice nginx para atender solicitudes (dinámicas para la aplicación, contenido estático directamente).
  2. Utilice el servidor web Python para ofrecer contenido dinámico.

Dos de las soluciones más rápidas para un servidor web basado en Python son:

Debe buscar en Google para encontrar la mejor configuración actual para Django (aún en desarrollo).

Estoy usando nginx (0.6.32 tomado de sid) con mod_wsgi.Funciona muy bien, aunque no puedo decir si es mejor que las alternativas porque nunca probé ninguna.Nginx tiene memcached soporte integrado, que tal vez pueda interoperar con el middleware de almacenamiento en caché de Django (en realidad no lo uso, en lugar de eso, lleno el caché manualmente usando python-memcache y lo invalido cuando se realizan cambios), por lo que los accesos al caché omiten completamente a Django (mi desarrollo La máquina puede atender alrededor de 3000 solicitudes por segundo).

Una advertencia:nginx’ mod_wsgi No le gustan mucho las ubicaciones con nombre (intenta pasarlas en SCRIPT_NAME), entonces lo obvio 'error_page 404 = @django’ provocará numerosos errores oscuros.Tuve que parchear la fuente mod_wsgi para solucionarlo.

También estoy luchando por comprender todas las opciones.En esta publicación de blog Encontré algunos beneficios de mod_wsgi en comparación con mod_python explicados.

Múltiples sitios con poco tráfico en un VPS pequeño hacen que el consumo de RAM sea la principal preocupación, y mod_python parece una mala opción allí.Usando lighttpd y FastCGI, logré reducir el uso mínimo de memoria de un sitio Django simple a 58 MiB virtuales y 6,5 MiB residentes (después de reiniciar y atender una única solicitud sin mucha RAM).

He notado que la actualización de Python 2.4 a 2.5 en Debian Etch aumentó la huella mínima de memoria de los procesos de Python en un pequeño porcentaje.Por otro lado, la mejor gestión de la memoria de 2.5 podría tener un efecto opuesto mayor en los procesos de larga ejecución.

Mantenlo simple: Django recomienda Apache y mod_wsgi (o mod_python).Si servir archivos multimedia es una parte muy importante de su servicio, considere Amazon S3 o Rackspace CloudFiles.

En mi opinión, la mejor y más rápida pila es barniz-nginx-uwsgi-django.Y lo estoy usando con éxito.

Si estás usando lighthttpd, también puedes usar FastCGI para servir Django.No estoy seguro de cómo se compara la velocidad con mod_wsgi, pero si la memoria funciona correctamente, obtendrás un par de beneficios que obtendrías con mod_wsgi y que no obtendrías con mod_python.El principal es que puedes darle a cada aplicación su propio proceso (lo cual es realmente útil para mantener separada la memoria de diferentes aplicaciones, así como para aprovechar las computadoras con múltiples núcleos).

Editar:Solo para agregar con respecto a su actualización sobre nginix, si la memoria vuelve a funcionar correctamente, nginix usa "greenlets" para manejar la concurrencia.Esto significa que es posible que tengas que ser un poco más cuidadoso para asegurarte de que una aplicación no consuma todo el tiempo del servidor.

Usamos nginx y FastCGI para todas nuestras implementaciones de Django.Esto se debe principalmente a que normalmente implementamos en Slicehost y no queremos donar toda nuestra memoria a Apache.Supongo que este sería nuestro "caso de uso".

En cuanto a los comentarios acerca de que la documentación está principalmente en ruso, encontré la mayor parte de la información en el wiki en inglés ser muy útil y preciso.Este sitio también tiene configuraciones de muestra para Django, desde las cuales puede modificar su propia configuración de nginx.

Hay muchas maneras de hacer esto. Por esa razón, recomiendo leer atentamente el artículo relacionado con el proceso de implementación en DjangoAdvent.com:Eric Florenzano - Implementación de Django con FastCGI: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/ Lea también:Mike Malone - Blog de Django Django Stochastictechnologies:La configuración de Django perfecta Mikkel Hoegh Blog:35 % Mejora del tiempo de respuesta-cambio-uwsgi-nginx

Saludos

Tengo una advertencia por usar Cherokee.Cuando realiza cambios en Django Cherokee mantiene el proceso ANTIGUO, en lugar de eliminarlo y comenzar uno nuevo.

Sobre Apache, recomiendo encarecidamente este artículo.

http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl

Es fácil de configurar, fácil de eliminar o restablecer después de realizar cambios.

Simplemente escribe en la terminal

sudo /etc/init.d/apache2 restart

y los cambios se ven al instante.

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