WSGI vs uWSGi z Nginx [zamknięte]

Czy ktoś mógłby wyjaśnić zalety / wady korzystania z WSGI VS uWSGI z Nginx.

Obecnie buduję serwer produkcyjny dla serwisu Django, który przygotowałem, ale nie mogę zdecydować, czy powinienem wybrać WSGI czy uWSGI. Czy mógłbyś szczegółowo wyjaśnić, co wyróżnia każdą konfigurację? Która konfiguracja powinna się najlepiej skalować?

Z góry dziękuję

— macierz_strachu
źródło

Ten wpis na blogu jest bardzo szczegółowym porównaniem wielu serwerów Python WSGI, z podsumowaniem i kilkoma zaleceniami na końcu.

— Lowe Thiderman,

A także używa konfiguracji dla niektórych serwerów, które są naprawdę podejrzane i sprawiają, że wyglądają gorzej niż mogą być. Trzeba uważać, co się czyta w tym porównaniu.

— Graham Dumpleton

WSGI to specyfikacja. uWSGI zapewnia implementację specyfikacji WSGI. Nie możesz ich porównać. Możesz porównać tylko różne implementacje.

— Graham Dumpleton

Odpowiedzi:

101

Ok, to zamieszanie jest spowodowane brakiem szczegółów z kilku źródeł, nazewnictwem tych protokołów i tym, czym właściwie jest WSGI.

Podsumowanie:

WSGI i uwsgi oba są protokoły, a nie serwerach. Służy do komunikacji z serwerami sieciowymi w celu równoważenia obciążenia, a zwłaszcza do korzystania z dodatkowych funkcji, których nie zapewnia czysty HTTP. Do tej pory Nginx i Cherokee zaimplementowały ten protokół.
uWSGI to serwer, a jednym z protokołów, które implementuje, jest WSGI (nie należy mylić protokołu uwsgi z serwerem uWSGI). WSGI to specyfikacja Pythona . Istnieje kilka implementacji specyfikacji WSGI i jest ona przeznaczona do użycia nie tylko dla serwerów aplikacji / serwerów WWW, ale istnieje sporo serwerów aplikacji WSGI (np. CherryPy, który również ma produkcyjny serwer WWW zgodny ze standardem WSGI , jeśli nie byłeś już wystarczająco zdezorientowany!).
Porównywanie uwsgi do WSGI to porównywanie pomarańczy do jabłek.

— Derek Litz
źródło

Typo: "1. uwsgi to protokół, a nie serwer." -> "1. WSGI jest protokołem, a nie serwerem."

— Aman

Właściwie to co napisałem dla 1 jest poprawne, ale to prawda, WSGI jest protokołem tak samo jak uwsgi, więc oba napisane przez Ciebie stwierdzenia są poprawne :). Oczywiście bez reszty kontekstu 1. Jest to protokół używany przez serwer uWSGI. wiki.nginx.org/HttpUwsgiModule , - "Nie myl protokołu uwsgi z serwerem uWSGI (który mówi w protokole uwsgi)"

— Derek Litz

Ah, dobrze. Myślałem, że próbujesz narysować kontrast między instrukcją 1. „wsgi to protokół ..” a 2. „uwsgi to serwer implementujący protokół”.

— Aman

@DerekLitz, Na których serwerach działa django, kiedy to robimy python manage.py runserver?

— Piyush S. Wanare

python manage.py runserverto wewnętrzny serwer wbudowany w Django. To nie jest apache, nginx, gunicorn czy cokolwiek innego. django-extensionszapewnia, runserver_plusże używa frameworka Werkzeug, ale jest tak blisko serwera, jak to tylko możliwe runserver.

— Mike DeSimone

Ogólnie najlepiej jest uruchamiać Pythona w oddzielnym procesie od głównego serwera WWW. W ten sposób serwer WWW może mieć wiele małych wątków, które bardzo szybko obsługują statyczną zawartość, podczas gdy twoje oddzielne procesy Pythona będą duże i ciężkie, a każdy z nich będzie uruchamiał własny interpreter Pythona. Tak proste WSGIjest złe, ponieważ nadyma każdy z twoich wątków nginx dużym interpreterem Pythona. Korzystanie fluplub gunicornlub uWSGIza nginxto o wiele lepiej, bo to uwalnia nginx po prostu służyć zawartości i pozwala wybrać ile drobne nitki światła nginx biegać, niezależnie od wyboru, ile ciężkiej wątków Python przywołać służyć dynamicznej zawartości. Ludzie wydają się gunicornw tej chwili bardzo zadowoleni , ale każda z tych trzech opcji powinna działać dobrze.

Idąc dalej, pozwala również na przeniesienie Pythona na inny serwer, gdy obciążenie zaczyna być poważne.

— Brandon Rhodes
źródło

Twoja odpowiedź jest trochę zdezorientowana. Nie widzę, żeby wspomniał o uruchamianiu jakiejkolwiek implementacji WSGI wewnątrz nginx. Odwołał się do głównej witryny wsgi.org. Jego oryginalne porównanie WSGI i uWSGI jest więc przede wszystkim trochę głupie, ponieważ uWSGI jest implementacją specyfikacji WSGI. Sam użyłeś ogólnego terminu WSGI w mylący sposób, mówiąc, że „nadyma on każdy pojedynczy wątek nginx za pomocą dużego interpretera Pythona”. Sama specyfikacja WSGI nie może tego zrobić, tylko implementacje mogą.

— Graham Dumpleton

Miałoby sens, gdybyśmy porównali nginx + mod_wsgi (moduł podłączany) i nginx + uWSGI (kontener serwera aplikacji).

— clime

Więc jeśli chodzi o używanie Nginx do uruchamiania aplikacji internetowych Python, ponieważ mod_wsgi Manlio Perillo jest martwe i nie jest zalecane, dobrym rozwiązaniem jest WSGI z gunicorn lub uWSGI lub FastCGI z Flupem?

— Gulbahar

Uważam, że właśnie tutaj http://flask.pocoo.org/docs/deploying/uwsgi/ jest dobrą odpowiedzią na wyjaśnienie zamieszania. Pytanie nie jest głupie, zdarza się każdemu, kto widzi te dwa terminy i nie ma wcześniejszych informacji o tym, jak działają rzeczy poza światem mod_PHP (np. Nic przeciwko php lub ludziom)

Witryna dobrze radzi sobie z praktycznym wyjaśnieniem, co jest potrzebne i jaka jest różnica, a także dobry przykład wdrożenia nginx.

Dla wygody zacytowano tutaj wyjaśnienie z Flask wiki:

uWSGI to opcja wdrażania na serwerach takich jak nginx, lighttpd i cherokee; zobacz FastCGI i samodzielne kontenery WSGI, aby zapoznać się z innymi opcjami. Aby używać aplikacji WSGI z protokołem uWSGI, będziesz potrzebować najpierw serwera uWSGI. uWSGI jest zarówno protokołem, jak i serwerem aplikacji; serwer aplikacji może obsługiwać protokoły uWSGI, FastCGI i HTTP.

Najpopularniejszym serwerem uWSGI jest uwsgi, którego użyjemy w tym przewodniku. Upewnij się, że jest zainstalowany, aby postępować zgodnie z instrukcjami.

— Abhishek Dujari
źródło