WSGI vs uWSGi con Nginx [chiuso]

Qualcuno potrebbe spiegare i pro / contro quando si usa WSGI VS uWSGI con Nginx.

Attualmente sto costruendo un server di produzione per il sito Web Django che ho preparato ma non sono in grado di decidere se devo andare con WSGI o uWSGI. Potresti spiegare in dettaglio cosa differenzia ogni configurazione? Quale configurazione dovrebbe scalare meglio?

Grazie in anticipo

— fear_matrix
fonte

Questo post del blog è un confronto molto dettagliato di molti server WSGI Python, con un riepilogo e alcuni consigli alla fine.

— Lowe Thiderman

E utilizza anche configurazioni per alcuni server che sono davvero ingannevoli e li fanno sembrare peggiori di quanto possano essere. Bisogna stare attenti a ciò che si legge in quel confronto.

— Graham Dumpleton

WSGI è una specifica. uWSGI fornisce un'implementazione della specifica WSGI. Non puoi confrontarli. Puoi confrontare solo diverse implementazioni.

— Graham Dumpleton

Risposte:

101

Ok, ragazzi questa confusione è dovuta alla mancanza di dettagli da diverse fonti, alla denominazione di questi protocolli e a ciò che WSGI è effettivamente.

Sommario:

WSGI e uwsgi SONO entrambi protocolli, non server. Viene utilizzato per comunicare con i server Web per il bilanciamento del carico e soprattutto per sfruttare le funzionalità extra che il puro HTTP non può fornire. Finora Nginx e Cherokee hanno implementato questo protocollo.
uWSGI è un server e uno dei protocolli che implementa è WSGI (non confondere il protocollo uwsgi con il server uWSGI). WSGI è una specifica Python . Esistono diverse implementazioni della specifica WSGI ed è inteso per essere utilizzato per più di semplici server di applicazioni / server Web, ma ci sono parecchi server di applicazioni WSGI (ad esempio CherryPy, che ha anche un server Web conforme a WSGI pronto per la produzione , se non eri già abbastanza confuso!).
Confrontare uwsgi con WSGI significa confrontare le arance con le mele.

— Derek Litz
fonte

Errore di battitura : "1. uwsgi è un protocollo, non un server." -> "1. WSGI è un protocollo, non un server."

— Aman

In realtà, quello che ho scritto per 1 è corretto, ma è vero WSGI è un protocollo così come uwsgi, quindi entrambe le affermazioni che hai scritto sono corrette :). Ovviamente, senza il resto del contesto 1. È il protocollo utilizzato dal server uWSGI. wiki.nginx.org/HttpUwsgiModule , - "Non confondere il protocollo uwsgi con il server uWSGI (che parla il protocollo uwsgi)"

— Derek Litz

Ah ok. Pensavo stessi cercando di tracciare un contrasto tra l'istruzione 1. "wsgi è un protocollo .." e 2. "uwsgi è un server che implementa il protocollo".

— Aman

@DerekLitz, su quali server gira django quando lo facciamo python manage.py runserver?

— Piyush S. Wanare

python manage.py runserverè un server interno integrato in Django. Non è apache, nginx, gunicorn o qualsiasi altra cosa. django-extensionsfornisce un runserver_plusche utilizza il framework Werkzeug, ma è il più vicino possibile a un server runserver.

— Mike DeSimone

In genere è meglio eseguire Python in un processo separato dal tuo server web principale. In questo modo, il server web può avere molti piccoli thread che servono contenuto statico molto velocemente, mentre i tuoi processi Python separati saranno grandi e pesanti e ognuno eseguirà il proprio interprete Python. Così semplice WSGIè un male, perché riempie ogni singolo thread nginx con un grande interprete Python. Usare flupo gunicorno uWSGIdietro nginxè molto meglio, perché ciò libera nginx per servire semplicemente il contenuto e ti consente di scegliere quanti piccoli thread nginx leggeri eseguire, indipendentemente dalla tua scelta di quanti thread Python pesanti porti per servire il contenuto dinamico. Le persone sembrano molto soddisfatte gunicornin questo momento, ma ognuna di queste tre opzioni dovrebbe funzionare bene.

Andando avanti, ti libera anche per spostare Python su un altro server quando il carico inizia a diventare serio.

— Brandon Rhodes
fonte

Sono un po 'confuso dalla tua risposta. Non vedo che abbia menzionato l'esecuzione di qualsiasi tipo di implementazione WSGI all'interno di nginx. Ha fatto riferimento al sito principale wsgi.org. Il suo confronto originale tra WSGI e uWSGI è quindi un po 'sciocco in primo luogo perché uWSGI è un'implementazione della specifica WSGI. Tu stesso hai usato il termine WSGI generico in modo confuso dicendo che "riempie ogni singolo thread nginx con un grande interprete Python". La specifica WSGI non può farlo, solo le implementazioni possono farlo.

— Graham Dumpleton

Potrebbe avere senso confrontare nginx + mod_wsgi (il modulo inseribile) e nginx + uWSGI (il contenitore del server delle applicazioni).

— clima

Quindi, quando si tratta di utilizzare Nginx per eseguire app Web Python, dal momento che mod_wsgi di Manlio Perillo è deadware e non è raccomandato, le buone soluzioni sono WSGI con gunicorn o uWSGI o FastCGI con Flup?

— Gulbahar

Credo che questo qui http://flask.pocoo.org/docs/deploying/uwsgi/ sia una buona risposta per chiarire la confusione. La domanda non è sciocca, succede a chiunque veda i due termini e non ha informazioni precedenti su come funzionano le cose al di fuori del mondo mod_PHP (per esempio niente contro php o gente)

Il sito fa bene a spiegare in termini pratici cosa è necessario e qual è la differenza, nonché un buon esempio di distribuzione per nginx.

Per comodità, la spiegazione dal wiki di Flask è citata qui:

uWSGI è un'opzione di distribuzione su server come nginx, lighttpd e cherokee; vedere FastCGI e contenitori WSGI autonomi per altre opzioni. Per usare la tua applicazione WSGI con il protocollo uWSGI avrai prima bisogno di un server uWSGI. uWSGI è sia un protocollo che un server delle applicazioni; il server delle applicazioni può servire i protocolli uWSGI, FastCGI e HTTP.

Il server uWSGI più popolare è uwsgi, che useremo per questa guida. Assicurati di averlo installato per seguirlo.

— Abhishek Dujari
fonte