Dlaczego potrzebuję nginx, gdy mam uWSGI

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?

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.

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.