Odpowiedzi:
Skupię się na powolnym zachowaniu klienta i tym, jak radzi sobie z tym Twoja konfiguracja, ale nie daj się uwierzyć, że to jedyna korzyść. Ta sama metoda, która przynosi korzyści powolnym klientom, ma również zalety dla szybkich klientów, obsługi protokołu SSL, radzenia sobie z skokami ruchu i innych aspektów obsługi HTTP w Internecie.
Gunicorn to oprogramowanie do wstępnego rozwidlania. W przypadku komunikacji o niskim opóźnieniu, takiej jak moduł równoważenia obciążenia z serwerem aplikacji lub komunikacja między usługami, systemy przed rozwidleniem mogą być bardzo skuteczne. Uruchomienie procesu obsługi żądania nie wiąże się z żadnymi kosztami, a pojedynczy proces może być dedykowany do obsługi pojedynczego żądania; wyeliminowanie tych rzeczy może doprowadzić do ogólnie szybszego, bardziej wydajnego systemu, dopóki liczba jednoczesnych połączeń nie przekroczy liczby dostępnych procesów do ich obsługi.
W twojej sytuacji masz do czynienia z klientami o wysokim opóźnieniu przez Internet. Ci powolni klienci mogą powiązać te same procesy. Gdy QPS ma znaczenie, kod aplikacji musi odebrać, obsłużyć i rozwiązać żądanie tak szybko, jak to możliwe, aby mógł przejść do innego żądania. Gdy powolni klienci komunikują się bezpośrednio z systemem, wiążą ten proces i spowalniają go. Zamiast obsługi i likwidacji żądania tak szybko, jak to możliwe, proces ten musi teraz także czekać na powolnego klienta. Efektywny QPS spada.
Obsługa dużej liczby połączeń przy bardzo niewielkich kosztach procesora i pamięci jest tym, w czym serwery asynchroniczne, takie jak Nginx, są dobre. Nie wpływają na nich w ten sam negatywny sposób powolni klienci, ponieważ są biegli w obsłudze dużej liczby klientów jednocześnie. W przypadku Nginx, działając na nowoczesnym sprzęcie, może obsłużyć dziesiątki tysięcy połączeń jednocześnie.
Nginx przed serwerem przed rozwidleniem to świetne połączenie. Nginx obsługuje komunikację z klientami i nie ponosi kary za obsługę powolnych klientów. Wysyła żądania do backendu tak szybko, jak backend może je obsłużyć, dzięki czemu backend może być tak efektywny przy użyciu zasobów serwera, jak to możliwe. Backend zwraca wynik natychmiast po jego obliczeniu, a bufory Nginx reagują na to, aby dostarczyć go powolnym klientom we własnym tempie. Tymczasem backend może przejść do obsługi kolejnego żądania, nawet gdy powolny klient nadal otrzymuje wynik.
@blueben ma rację. Konkretnym i częstym przykładem tego, co może się zdarzyć, gdy nie jest używane odwrotne proxy, jest to, że baza danych zaplecza może wyczerpać uchwyty połączeń z bazą danych, w których nie ma proxy i występuje gwałtowny wzrost ruchu. Jest to spowodowane powolnym uwalnianiem połączeń, jak opisano w @blueben.
Pierwszym instynktem do zobaczenia wyczerpania się uchwytów bazy danych może być obsługa większej liczby połączeń z bazą danych. Ale dodając odwrotne proxy przed aplikacją zobaczysz liczbę wymaganych połączeń z bazą danych dla dużego obciążenia zarówno spada znacząco, jak i stabilizuje się - poziom połączenia z bazą danych nie wzrośnie prawie tak samo, gdy wystąpi skok ruchu.
Nginx doskonale nadaje się także do obsługi zawartości statycznej, buforowania i wielu innych zadań HTTP, pozwalając serwerowi aplikacji skupić się na byciu serwerem aplikacji.