Sto usando nginx + fastcgi (manage.py runfcgi ...) in produzione per alcuni dei miei progetti Django. Un sacco di gente suggerisce di usare nginx + gunicorn. Qual è il vantaggio dell'uso di gunicorn invece di utilizzare il server fastcgi di Django?Qual è lo svantaggio di utilizzare il server Fastgigi di Django
Sono solo dire perché è necessario utilizzare i server WSGI simile :) ma se ti trovi bene con l'utilizzo di fcgi - basta usarlo
Risposta breve: WSGI (come protocollo) è fresco perché its native
O se "È necessario andare più in profondità" (c)
domanda successiva "FastCGI vs server simili a WSGI?"
Alcune risposte qui:
Chi gunicorn, uWSGI e cherokee, nginx. Non li mescoli!
nginx è un server Web in grado di gestire le richieste http e di inviarlo al back-end WSGI. (Ma prima di tutto è estremamente veloce per la gestione dei contenuti statici.) E il backend WSGI gestisce l'applicazione django.
A proposito di cherokee, penso che gestisca gli stessi compiti di nginx ma non ci lavoro.
E gunicorn, uWSGI sono backend WSGI che corrono le discussioni con Django app e fare many other tasks
E hmmm, gunicorn say che
Essendo un server che gira solo su piattaforme Unix-like, unicorno è fortemente legato alla filosofia Unix di fare una cosa e (si spera) farlo bene. Nonostante l'utilizzo di HTTP, l'unicorno è strettamente un server di applicazioni back-end per l'esecuzione di applicazioni Ruby Ruby.
io pratico per il mio Django apps nginx (ultima versione stabile da nginx.org pronti contro termine) + uWSGI (dalle stalle Debian) - funziona perfettamente :)
modificati 18.05.2012
link al 2010 argomento con il confronto fcgi gunicorn uWSGI
fcgi (filettata) 640 r/s
fcgi (prefork 4 processori) 240 r/s (*)
gunicorn (2 lavoratori) 1100 r/s
gunicorn (5 lavoratori) 1300 R/s
gunicorn (10 wo rkers) 1200 R/s (?!?)
uwsgi (2 lavoratori) 1800 giri/s
uwsgi (5 lavoratori) 2100 r/s
uwsgi (10 lavoratori) 2300 r/s
(* questo ha reso il mio computer eccezionalmente lento come CPU quando attraverso il tetto)
"FastCGI vs. WSGI" è la domanda sbagliata. FastCGI è un protocollo di rete e WSGI è una convenzione di chiamata Python. [flup] (http://trac.saddi.com/flup) ha un gateway da FastCGI a WSGI. Il comando 'runfcgi' di Django è in realtà basato su flup e quindi utilizza WSGI. Una domanda migliore è flup vs uwsgi o flup vs. gunicorn. –
Hai ragione su "FastCGI vs WSGI". Cambia argomento in WSGI. E penso che battaglia 'flup contro uwsgi contro gunicorn' vincerà uWSGI. Proverò a fornire alcune prove presto. – nk9
Bene, chi "vince" dipende da quali sono i tuoi criteri. Sto ospitando una dozzina di siti con poco traffico, quindi la facilità di manutenzione e l'utilizzo della memoria sono più importanti * per me * delle prestazioni non elaborate (che sono comunque dominate dalle query del database). Uwsgi non è incluso in debian squeeze (la stable corrente) , mentre sono flup e gunicorn. –
come B1- dice, WSGI è nativo (dare un'occhiata a this post).
Inoltre, this post ha una domanda simile.
Dal mio punto di vista personale, qualche tempo fa ho usato Nginx + uwsg in vhost mode per eseguire vari progetti sul mio server.
... e uWSGI ha la modalità zerg^_ ^ – nk9
Inoltre, guarda uwsgi. –
FastCGI Sconsigliata a partire da versione 1.7: il supporto FastCGI è deprecato e sarà rimosso in Django 1.9, quindi suggerisco andare per uWSGI.. – ashish