Ich verwende nginx + fastcgi (manage.py runfcgi ...) auf Produktion für einige meiner Django-Projekte. Viele Leute schlagen vor, nginx + gunicorn zu verwenden. Was ist der Vorteil der Verwendung von Gunicorn anstelle von Djangos fastcgi Server?Was ist der Nachteil der Verwendung von Django fastcgi Server
Ich bin nur sagen, warum Sie WSGI-like-Server verwenden müssen :) aber wenn Sie sich wohl fühlen mit fcgi mit - es ist nur
verwendenKurze Antwort: WSGI (als Protokoll) ist cool, weil its native
Oder wenn "Sie müssen tiefer gehen" (c)
Nächste Frage "FastCGI vs WSGI-like Server?"
Einige Antworten hier:
Über gunicorn, uwsgi und cherokee, nginx. Mischen Sie sie nicht!
nginx ist ein Webserver, der HTTP-Anfragen bearbeiten und an das WSGI-Backend senden kann. (Aber vor allem ist es extrem schnell für die Handhabung von statischen Inhalten.) Und WSGI Backend behandeln Sie Django-Anwendung.
Über Cherokee, denke ich, dass es die gleichen Aufgaben wie nginx behandelt, aber ich arbeite nicht damit.
Und gunicorn sind uwsgi WSGI-Backend, das Gewinde mit django app laufen und tun many other tasks
Und hmmm, gunicorn say dass
Sein ein Server, der nur auf Unix-ähnlichen Plattformen läuft, Einhorn stark ist gebunden an die Unix-Philosophie, eine Sache zu machen und (hoffentlich) es gut zu machen. Trotz der Verwendung von HTTP ist Unicorn ausschließlich ein Back-End-Anwendungsserver zum Ausführen von Rack-basierten Ruby-Anwendungen.
ich für meine django üben apps nginx (letzte stabile von nginx.org repos) + uwsgi (von Debian Stallungen) - funktioniert perfekt :)
18,05 bearbeitet.2012
Link zu 2010 Thema mit fcgi gunicorn uWSGI Vergleich
fcgi (Gewinde) 640 r/s
fcgi (prefork 4 Prozessoren) 240 r/s (*)
gunicorn (2 Arbeitnehmer) 1100 r/s
gunicorn (5 Arbeiter) 1300 R/s
gunicorn (10 WO rkers) 1200 r/s (?!?)
uwsgi (2 Arbeiter) 1800 U/s
uwsgi (5 Beschäftigte) 2100 r/s
uwsgi (10 Beschäftigte) 2300 r/s
(* dies machte mein Computer außerordentlich träge wie CPU, wenn durch das Dach)
"FastCGI vs. WSGI" ist die falsche Frage. FastCGI ist ein Netzwerkprotokoll und WSGI ist eine Python-Aufrufkonvention. [flup] (http://trac.saddi.com/flup) hat ein FastCGI-zu-WSGI-Gateway. Djangos 'runfcgi'-Befehl basiert auf Flup und verwendet WSGI. Eine bessere Frage ist Flup vs. Uwsgi oder Flup vs Gunicorn. –
Sie haben recht mit "FastCGI vs WSGI". Ändern Sie das Thema in WSGI-like. Und ich glaube, der Kampf 'Flup vs. uwsgi vs gunicorn' gewinnt uWSGI. Ich werde versuchen, bald Beweise zu liefern. – nk9
Nun, wer "gewinnt" hängt davon ab, was Ihre Kriterien sind. Ich hosste ein Dutzend Seiten mit wenig Traffic, daher sind Wartungsfreundlichkeit und Speichernutzung für mich wichtiger * als rohe Leistung (die ohnehin von Datenbankabfragen dominiert wird.) Uwsgi ist nicht in Debian Squeeze (der aktuelle stabile) verpackt , während Flup und Gunicorn sind. –
wie B1- sagt, WSGI stammt (einen Blick auf this post nehmen).
Auch this post hat eine ähnliche Frage.
Aus meiner persönlichen Sicht habe ich vor einiger Zeit Nginx + uwsg in vhost mode verwendet, um verschiedene Projekte auf meinem Server laufen zu lassen.
... und uWSGI hat Zerg-Modus^_ ^ – nk9
Siehe auch uwsgi. –
FastCGI Veraltet seit Version 1.7: Die FastCGI-Unterstützung ist veraltet und wird in Django 1.9 entfernt. Daher rate ich Ihnen, sich für uWSGI zu entscheiden. – ashish