Ilu połączeń roboczych serwera reverse proxy potrzebują wznawialne przesyłania?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Many Reverse-Proxy Worker Connections Do Resumable Uploads Need? - Zima Store Online

Nie ma jednej bezpiecznej, uniwersalnej liczby połączeń obsługiwanych przez worker w przypadku wznawialnych przesyłań. Ustal ją na podstawie największego odtwarzalnego zapotrzebowania na jednoczesne gniazda, a następnie dodaj zmierzony zapas.

Na domowym serwerze pojedyncze widoczne przesyłanie może utrzymywać połączenie klienta, połączenie z serwerem nadrzędnym oraz okresy bezczynności między fragmentami, gdy przeglądarka ponawia próbę lub wznawia przesyłanie. Zacznij od bieżącej liczby połączeń w najbardziej obciążonym, typowym oknie przesyłania, porównaj ją z limitami serwera proxy i systemu operacyjnego, a następnie przestań zwiększać ustawienie proxy, jeśli wcześniej wyczerpią się deskryptory plików, workery serwera nadrzędnego, pamięć lub aplikacja ulegnie awarii.

Zmierz bieżące zapotrzebowanie na połączenia podczas przesyłania przed wyborem limitu

Liczyć należy połączenia podczas rzeczywistego obciążenia, a nie wtedy, gdy proxy jest bezczynne. Rozpocznij tyle przesyłań, ile prawdopodobnie będzie jednocześnie uruchamiać Twoje gospodarstwo domowe lub mały zespół, wstrzymaj i wznów kilka transferów oraz uwzględnij klienta mobilnego, który ponownie łączy się po wybudzeniu. Zapisz liczbę zaakceptowanych gniazd klientów, ustanowionych gniazd serwera nadrzędnego oraz połączeń oczekujących na odpowiedź serwera nadrzędnego.

Limit workerów jest wykorzystywany przez wszystkie otwarte połączenia obsługiwane przez danego workera, a nie tylko przez ukończone żądania HTTP. Dlatego podczas pomiaru należy uwzględnić połączenia serwera proxy wraz z połączeniami klientów.

Jako bazę roboczą przyjmij najwyższą powtarzalną łączną wartość. Jeśli suma rośnie wyłącznie podczas lawiny ponownych połączeń i szybko spada, traktuj ten skok oddzielnie od stałego zapotrzebowania. Jeśli nadal rośnie, mimo że przepustowość przesyłania pozostaje bez zmian, nie uznawaj rosnącej liczby za rzeczywistą przepustowość; zanim cokolwiek zwiększysz, sprawdź aplikację serwera nadrzędnego, limity czasu i zablokowane sesje.

Przelicz zapotrzebowanie na gniazda na przepustowość pojedynczego workera

W przypadku odwrotnego serwera proxy jedno aktywne przesyłanie zwykle jednocześnie zajmuje połączenie po stronie klienta i połączenie po stronie serwera nadrzędnego. Dodatkowe miejsca zajmują HTTP keepalive, kontrole stanu, sesje WebSocket oraz ruch administracyjny. Traktuj dwukrotność liczby jednoczesnych przesyłań jako model początkowy, a nie ostateczną odpowiedź, ponieważ zmierzona łączna liczba gniazd jest wiarygodniejsza niż reguła kciuka.

Widoczny limit połączeń workera może odrzucać nowych klientów, nawet gdy ustanowione transfery nadal trwają. Porównaj najbardziej obciążonego workera z jego skonfigurowanym limitem, a następnie sprawdź limit otwartych plików procesu usługi; wyższa wartość proxy nie utworzy deskryptorów plików, których proces nie ma uprawnień otworzyć.

Wybierz wartość docelową wyższą od najbardziej obciążonego powtarzalnego wyniku workera, zapewniającą miejsce na zaobserwowany skok ponownych prób oraz zwykły ruch niezwiązany z przesyłaniem. Nie mnoż liczby przez każdego możliwego klienta i każdy fragment, jeśli te połączenia nigdy nie występują jednocześnie. Jeśli limit systemu operacyjnego jest niższy, najpierw dostosuj tę warstwę albo utrzymuj wartość docelową proxy poniżej tego limitu.

Przetestuj pierwotną ścieżkę wznawiania i zinterpretuj awarię

Powtórz dokładnie wyzwalający ją scenariusz: rozpocznij cały zestaw przesyłań, przerwij kilka klientów, a następnie wznów je, gdy pozostałe transfery są aktywne. Obserwuj akceptowanie nowych połączeń, czas ponawiania prób, przepustowość przesyłania, komunikaty błędów proxy, czas odpowiedzi serwera nadrzędnego oraz liczbę otwartych deskryptorów plików. Syntetyczne żądanie, które nigdy nie przesyła treści, nie testuje tej samej ścieżki zasobów.

Jeśli proxy zgłasza wyczerpanie połączeń workerów dokładnie w momencie, gdy nowe przesyłania kończą się niepowodzeniem, limit jest potwierdzonym wąskim gardłem. Jeśli nowe żądania kończą się błędem rozmiaru treści, przekroczenia limitu czasu, niedostępności serwera nadrzędnego lub kolejki aplikacji, podczas gdy wykorzystanie połączeń pozostaje poniżej limitu, wyższa wartość ustawienia workerów nie rozwiąże problemu. Obliczenie limitu połączeń nadal musi uwzględniać limit otwartych plików oraz dwustronne gniazda proxy.

Zmieniaj jedną warstwę naraz. Zwiększ limit workerów dopiero wtedy, gdy dzienniki i dane o gniazdach wskażą go jako przyczynę, przeładuj proxy i ponownie uruchom ten sam scenariusz przerwania. Jeśli błąd przeniesie się do usługi serwera nadrzędnego lub limitu deskryptorów plików, zatrzymaj się; oznacza to osiągnięcie kolejnego ograniczenia, a nie dowód, że jeszcze większa liczba połączeń proxy będzie przydatna.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Zapewnij wystarczający zapas i określ warunek zakończenia

Zachowaj odstęp między najbardziej obciążonym zaobserwowanym workerem a skonfigurowanym limitem, ale określ jego wielkość na podstawie rzeczywistych wahań. Mały serwer o stabilnym ruchu domowym potrzebuje mniej zapasowej rezerwy niż usługa publiczna otrzymująca nieprzewidywalne skoki obciążenia. Zapisz wartość bazową, cel, liczbę workerów, limit plików procesu oraz wynik szczytowy, aby kolejną zmianę można było porównać, a nie zgadywać.

Przepustowość połączeń to tylko jedna warstwa ścieżki przesyłania. Gdy panel działa, ale konkretna ścieżka synchronizacji lub przesyłania kończy się niepowodzeniem, nadal trzeba wyizolować wadliwy punkt końcowy i metodę, zanim uzna się proxy za sprawne.

Zmiana jest udana, gdy dwa pełne testy wznawiania zakończą się pomyślnie, nowe połączenia będą akceptowane, dzienniki błędów pozostaną czyste, a najbardziej obciążony worker zachowa stabilny zapas. Wycofaj zwiększenie, jeśli presja na pamięć lub opóźnienia wzrosną bez ograniczenia liczby awarii. Przejdź do analizy warstwy aplikacji lub pamięci masowej, gdy wykorzystanie połączeń pozostaje wyraźnie poniżej limitu, ale przesyłania nadal trafiają do kolejki, przekraczają limit czasu lub uszkadzają stan wznawiania.