Dlaczego potrzebuję nginx, gdy mam uWSGI

62

Istnieje wiele samouczków na temat konfigurowania nginx do współpracy z uWGSI, kiedy chcę wdrożyć aplikację Django.

Ale dlaczego potrzebuję nginx w tym zestawie? Sam uWSGI może obsługiwać aplikacje WSGI Python, może obsługiwać pliki statyczne, może także obsługiwać SSL. Co może zrobić Nginx, czego nie może uWSGI?

nginx django uwsgi

— użytkownik983447
źródło

9

Widzę, że to pytanie jest zamknięte z powodu opinii. Absolutnie się nie zgadzam. Pytanie „Co może zrobić Nginx, czego nie może uWSGI?” jest oparty na faktach.

— user983447

1

Zasadniczo nie przemawiam za ponownym otwarciem, ale w tym przypadku się zgadzam. Istniejąca pozytywnie zaakceptowana odpowiedź jest dobra, co pokazuje, że pytanie, jak napisano, dopuszcza rozsądnych i odpowiednich odpowiedzi; Myślę, że prawdopodobnie to dobre pytanie.

— MadHatter

55

Ty nie.

W każdym razie to prosta odpowiedź - nie potrzebujesz jej. uWSGI sam w sobie jest zdolnym serwerem.

Jednak inne serwery, takie jak nginx, istnieją już dłużej i są (prawdopodobnie w każdym razie) bezpieczniejsze, a także mają dodatkowe funkcje nieobsługiwane przez uWSGI - na przykład ulepszoną obsługę zasobów statycznych (za pomocą dowolnej kombinacji Expires lub E-Tag nagłówki, kompresja gzip, wstępnie skompresowany gzip itp.), które mogą znacznie zmniejszyć obciążenie serwera i sieci; dodatkowo serwer taki jak nginx przed aplikacją Django może również implementować buforowanie zawartości dynamicznej, co dodatkowo pomaga zmniejszyć obciążenie serwera, a nawet pomaga w korzystaniu z sieci CDN (która zwykle nie radzi sobie z treścią dynamiczną ). Możesz nawet pójść dalej i mieć nginx na całkowicie oddzielnym serwerze, odwracając żądania proxy dotyczące treści dynamicznej do klastra serwerów aplikacji z równoważeniem obciążenia, jednocześnie obsługując samą zawartość statyczną.

Na przykład mój blog (chociaż jest WordPress, ma przed sobą nginx) jest dostrojony do buforowania postów przez 24 godziny i do buforowania stron indeksu przez 5 minut; chociaż nie widzę wystarczającego ruchu, aby to naprawdę miało znaczenie, pomaga mojemu maleńkiemu VPS'owi przetrwać sporadyczny wzrost, który w przeciwnym razie mógłby go zepsuć - taki jak duży wzrost ruchu, gdy jeden z moich artykułów został wybrany przez Twitterera z wieloma tysiącami obserwujących, z których wielu ponownie napisało na Twitterze do swoich tysięcy obserwujących.

Gdybym działał na „pustym” serwerze uWSGI (i zakładając, że był to raczej serwis Django niż WordPress), to mógł się z tym pogodzić - lub mógł się zawiesić i spalić, co kosztowało mnie brakujących gości . Posiadanie nginx przed nim do obsługi tego obciążenia może naprawdę pomóc.

Biorąc to wszystko pod uwagę, jeśli prowadzisz małą witrynę, która nie generuje dużego ruchu, nie ma potrzeby korzystania z nginx ani niczego innego - wystarczy użyć uWSGI samodzielnie, jeśli tego chcesz. Z drugiej strony, jeśli zobaczysz duży ruch ... cóż, nadal możesz chcieć uWSGI, ale powinieneś przynajmniej rozważyć coś przed nim, aby pomóc w obciążeniu. W rzeczywistości powinieneś naprawdę testować różne konfiguracje gotowej witryny, aby określić, co będzie najlepsze dla Ciebie pod oczekiwanym obciążeniem, i użyj tego, co ostatecznie się skończy.

— Kromey
źródło

3

Jedną rzeczą, która przychodzi mi na myśl, którą warto zauważyć, oprócz tego, co @Kromey ujął w swojej odpowiedzi, jest to, że natywnym protokołem dla uWSGI nie jest http, ale protokół uwsgi. Protokół uwsgi jest prostszy i wydajniejszy w obsłudze niż HTTP, a zatem umieszczenie bardziej funkcjonalnego serwera WWW (nginx lub coś w tym stylu) przed aplikacją uWSGI nie powiela dużo przetwarzania i może zapewnić znaczące korzyści w zależności od twojego wymagania.

— Håkan Lindqvist

@ HåkanLindqvist jest całkowicie poprawny; dla wyjaśnienia, uWSGI jest w pełni zdolny do „mówienia” HTTP, jednak może sam sobie poradzić, ale tak, warto zauważyć, że serwer WWW przed nim używałby protokołu uwsgi, a nie HTTP, porozmawiaj z uWSGI, a zatem tak, bardzo mało powielania związanego z tym przetwarzania.

— Kromey

To dobra odpowiedź, można ją jednak ulepszyć za pomocą linku do własnej dokumentacji uWSGI na ten temat, która wyjaśnia bardziej szczegółowo, co można zrobić z uWSGI: uwsgi-docs.readthedocs.io/en/latest/…

— Tobias McNulty

1

IMO, jeśli umieścisz swoją witrynę w Internecie zamiast w Laboratorium, możesz zobaczyć różnicę.

Wyobraź sobie użytkownika z innego kraju z otwartą przeglądarką internetową o niskiej prędkości sieci, aby uzyskać dostęp do Twojej witryny. uWSGI obsłuży to połączenie HTTP w wątku. Wątek ten może długo czekać na pełne żądanie HTTP z powodu niskiej prędkości sieci. Jeśli twoja pula wątków wynosi 100, wyobraź sobie, że 100 użytkowników lubi tak wolno, co się stanie? Brak wątku bezczynnego do obsługi innych żądań HTTP.

Ale dla Nginx jest zupełnie inaczej. Nginx został zaprojektowany w „Reactor Pattern”. Możesz google „Reactor Pattern”, aby zobaczyć, jak to działa. Krótko mówiąc, wolne połączenie nie wpływa na obsługę innych żądań HTTP.

— Jcyrss
źródło

1

Wątpię, aby używanie Nginx to zmieni. Gdy aplikacja Django jest hostowana na Apache przy użyciu WSGI, funkcja widoku zostanie wywołana przed odczytaniem jakichkolwiek danych POST z gniazda. Więc jeśli klient jest wolny, będzie zajmował wątek od otrzymania żądania do czasu otrzymania danych POST. Dlaczego zastąpienie Apache Nginx miałoby to zmienić?

— kasperd

1

Jak wiem, domyślnie Nginx nie będzie proxy żądania HTTP do serwera aplikacji zaplecza, dopóki nie otrzyma pełnego żądania HTTP. Tak więc dla serwera aplikacji, takiego jak Django, zawsze uzyskują szybkie połączenie i żądanie HTTP, nie tracąc czasu na czekanie na kompletne żądanie HTTP, wkrótce po przetworzeniu zadania działający wątek może wkrótce zostać bezczynny dla następnego żądania HTTP.

— Jcyrss

1

Nazywa się to buforowaniem żądań, które jest domyślnie włączone w Nginx (w starszych wersjach Nginx nie można było tego wyłączyć): nginx.org/en/docs/http/…

— Tobias McNulty