Estoy usando nginx + fastcgi (manage.py runfcgi ...) en producción para algunos de mis proyectos de Django. Mucha gente sugiere usar nginx + gunicorn. ¿Cuál es la ventaja de usar gunicorn en lugar de usar el servidor fastcgi de Django?Cuál es la desventaja de utilizar el servidor fastcgi de Django
estoy solo decir por qué es necesario utilizar servidores WSGI-como :) pero si se siente cómodo con el uso fcgi - sólo lo utilizan
Respuesta corta: WSGI (como protocolo) es genial, porque its native
O si "Necesita profundizar" (c)
Siguiente pregunta "FastCGI vs WSGI-like servers?"
Algunas respuestas aquí:
Sobre gunicorn, uWSGI y Cherokee, nginx. ¡No los mezcles!
nginx es un servidor web que puede manejar solicitudes http y puede enviarlo al back-end de WSGI. (Pero antes que nada es extremadamente rápido para el manejo de contenido estático.) Y el backend de WSGI maneja la aplicación django.
Sobre cherokee, creo que maneja las mismas tareas que nginx pero no trabajo con eso.
Y gunicorn, uWSGI son backend WSGI que corren hilos con aplicación Django y hacer many other tasks
Y hmmm, gunicorn say que
Al ser un servidor que sólo se ejecuta en plataformas Unix, unicornio está fuertemente atado a la filosofía de Unix de hacer una cosa y (con suerte) hacerlo bien. A pesar de usar HTTP, unicorn es estrictamente un servidor de aplicaciones de back-end para ejecutar las aplicaciones de Ruby basadas en rack.
practico para mi Django apps de Nginx (la última estable de nginx.org repos) + uWSGI (de los establos de Debian) - funciona perfectamente :)
editado 18.05.2012
Enlace a 2,010 tema con la comparación de fcgi gunicorn uWSGI
fcgi (roscado) 640 r/s
fcgi (prefork 4 procesadores) 240 r/s (*)
gunicorn (2 trabajadores) 1100 r/s
gunicorn (5 trabajadores) 1300 r/s
gunicorn (10 wo rkers) 1200 r/s (?!?)
uwsgi (2 trabajadores) 1800 r/s
uwsgi (5 trabajadores) 2100 r/s
uwsgi (10 trabajadores) 2300 r/s
(* esto hizo que mi equipo excepcionalmente lento como CPU cuando a través del techo)
"FastCGI vs. WSGI" es la pregunta incorrecta. FastCGI es un protocolo de red y WSGI es una convención de llamadas de Python. [flup] (http://trac.saddi.com/flup) tiene una puerta de enlace FastCGI a WSGI. El comando 'runfcgi' de Django está basado en flup y, por lo tanto, usa WSGI. Una mejor pregunta es flup vs. uwsgi o flup vs. gunicorn. –
Tiene razón sobre "FastCGI vs. WSGI". Cambio en el tema a WSGI. Y creo que la batalla 'flup vs. uwsgi vs. gunicorn' gana UWSGI. Trataré de proporcionar algunas pruebas pronto. – nk9
Bueno, quién "gana" depende de cuál es su criterio. Estoy alojando una docena de sitios con poco tráfico, por lo que la facilidad de mantenimiento y el uso de memoria son más importantes * para mí * que el rendimiento bruto (que está dominado por consultas de bases de datos de todos modos). Uwsgi no está empaquetado en debian squeeze (el actual estable) , mientras que flup y gunicornio sí. –
como dice b1-, WSGI es nativa (echar un vistazo a this post).
Además, this post tiene preguntas similares.
Desde mi punto de vista personal, hace algún tiempo he estado usando Nginx + uwsg in vhost mode para ejecutar varios proyectos en mi servidor.
... y uWSGI tiene modo zerg^_ ^ – nk9
Además, mira uwsgi. –
FastCGI Desaprobado desde la versión 1.7: la compatibilidad con FastCGI está en desuso y se eliminará en Django 1.9. Por lo tanto, sugiero ir a uWSGI. – ashish