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ć?
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
25
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.
Typo: "1. uwsgi to protokół, a nie serwer." -> "1. WSGI jest protokołem, a nie serwerem."
Aman
9
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
4
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
2
@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
32
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.
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ą.
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
19
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.
Odpowiedzi:
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:
źródło
python manage.py runserver?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żliwerunserver.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. KorzystaniefluplubgunicornlubuWSGIzanginxto 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.
źródło
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:
źródło