Dlaczego miałbyś kiedykolwiek ustawiać MaxKeepAliveRequests na coś innego niż nieograniczony?

11

Apache KeepAliveTimeoutistnieje, aby zamknąć połączenie podtrzymujące połączenie, jeśli nowe żądanie nie zostanie wydane w określonym czasie. Pod warunkiem, że użytkownik nie zamknie przeglądarki / karty, ten limit czasu (zwykle 5-15 sekund) ostatecznie zamyka większość utrzymywanych połączeń i zapobiega marnowaniu zasobów serwera przez utrzymywanie połączeń na czas nieokreślony.

Teraz MaxKeepAliveRequestsdyrektywa ogranicza liczbę żądań HTTP KeepAliveobsługiwanych przez pojedyncze połączenie TCP (pozostawione otwarte z powodu ). Ustawienie tej wartości 0oznacza, że ​​dozwolona jest nieograniczona liczba żądań.

Dlaczego miałbyś kiedykolwiek ustawiać to na coś innego niż „nieograniczony”? Pod warunkiem, że klient nadal aktywnie wysyła żądania, jaka szkoda może pozwolić mu na to samo połączenie podtrzymujące połączenie? Po osiągnięciu limitu żądania wciąż przychodzą, tylko przy nowym połączeniu.

Z mojego punktu widzenia nie ma sensu ograniczać tego. czego mi brakuje?

apache-http-server http keepalive Jonathon Reinhart
źródło

Odpowiedzi:

4

Zasadniczo, ponieważ Apache nie został do tego stworzony. Problemem jest użycie pamięci serwera. W wielu konfiguracjach generowanie treści odbywa się w tym samym procesie, co dostarczanie treści, więc każdy proces powiększy się do wielkości największej obsługiwanej rzeczy. Wyobraź sobie proces rozwijający się do 64 MB z powodu ciężkiego skryptu php, a następnie ten rozdęty proces siedzący i serwujący pliki statyczne. Teraz pomnóż to przez 100. Ponadto, jeśli dojdzie do wycieku pamięci, procesy będą rosły bez ograniczeń.

Ustawienia utrzymywania aktywności powinny być zrównoważone w zależności od rodzaju treści i ruchu. Zasadniczo optymalna konfiguracja ma wysoką wartość MaxKeepAliveRequests (100-500), a KeepAliveTimeout niską wartość (2-5), aby szybko je zwolnić.

Sterowiec
źródło
2

Wiem, że to stare pytanie, ale debugowałem i wydaje się, że (i nie dotyczy to tylko Apache) MaxKeepAliveRequestsdziała niezależnie KeepAliveTimeout.

Oznacza to, że dyrektywa o przekroczeniu limitu czasu liczy się tylko dla bezczynnych trwałych połączeń (bez odczytu lub zapisu) - jeśli nadal żądasz poniżej limitu czasu, możesz praktycznie wykonać nieograniczoną liczbę żądań przez to samo połączenie.

Może to nie być dobre z niektórych powodów, w tym przypadkowego zabijania długo działających połączeń TCP? W każdym razie klienci HTTP nie są aż tak głupi i MaxKeepAliveRequestscałkiem dobrze radzą sobie z ustawieniem „niskiego” , np. W języku programowania stosunkowo łatwo jest wykryć, czy serwer został zamknięty przez połączenie TCP i ponownie się z nim łączy. Ponadto większość klientów HTTP będzie miała własne ograniczenia (np. Przeglądarki zamkną połączenie utrzymujące aktywność po około 300 sekundach).

lifeofguenter
źródło
1

Jednym z powodów byłoby równoważenie obciążenia. Po nawiązaniu połączenia utrzymującego połączenie lub protokołu HTTP 1.1 moduł równoważenia obciążenia nie przeniesie go na nowy host, dopóki się nie zamknie. Jeśli masz jednego klienta wysyłającego ogromną liczbę żądań za pośrednictwem jednego połączenia, możesz nie uzyskać dobrego balansu między serwerami.

dtauzell
źródło
Ale dlaczego miałoby to mieć znaczenie? Wydaje mi się niepożądane rozsyłanie połączenia jednego użytkownika na wiele serwerów. Równoważenie obciążenia ma obsługiwać dużą liczbę użytkowników, a nie połączenia od jednego użytkownika. W rzeczywistości - jeśli pojedynczy użytkownik wbija usługę, wolisz ograniczyć ją do pojedynczego serwera (na którym sami skutecznie ograniczaliby stawki).
Jonathon Reinhart
1
Słuszne uwagi. Kilka myśli: 1. ktokolwiek inny na tym serwerze również zostałby wkurzony. 2. W przypadku modułów równoważenia obciążenia, które działają poniżej poziomu HTTP: po wyjęciu serwera z puli modułu równoważenia obciążenia nie zamyka on istniejącego połączenia HTTP. To sprawia, że ​​trudniej jest przenosić ludzi na inny serwer za pomocą tylko modułu równoważenia obciążenia. Powodem 2 jest to, jak doszedłem do tej strony, szukając, co ludzie mają do powiedzenia na temat tego parametru.
dtauzell
1
Trzeci powód: jeśli twój serwer / aplikacja popadnie w zły stan i popełnia błąd, to przypinanie może sprawić, że wszystkie żądania będą błędne, dopóki sytuacja nie zostanie naprawiona, a jeśli ograniczysz liczbę osób, które mają szansę na zrównoważenie na nowym serwerze .
dtauzell
Nie spotkałem modułu równoważenia obciążenia, który działa w ten sposób. Moduł równoważenia obciążenia ma zwykle parametr „lepkości”, który określa, czy wszystkie żądania klienta (określone na przykład przez IP) w ramach bieżącej sesji powinny być kierowane do tego samego łącza nadrzędnego, czy rozłożone między strumieniami. Która opcja jest użyteczna, zależy od aplikacji, która biegnie w górę
Manuel
1

Częściowo, aby jeden użytkownik nie blokował wszystkich gniazd połączeń. Bez ograniczeń jeden złośliwy lub źle napisany klient może przejąć każde dostępne połączenie i zachować je na zawsze. Nie jest to jednak świetne ograniczenie w porównaniu do czegoś takiego jak limit połączeń na IP.

Głównie równoważenie obciążenia, ale szczególnie w odniesieniu do konserwacji. Jeśli chcesz przełączyć serwer w tryb offline, upuść go na 0 połączeń, ale pozwól, aby istniejące połączenia zakończyły się przez pewien czas. Ograniczenie liczby żądań utrzymywania aktywności oznacza, że ​​ostatecznie użytkownicy z wdziękiem utworzą nowe połączenie i zostaną przeniesieni na nowy serwer zaplecza. Prawdopodobnie jakiś sposób, aby zasygnalizować serwerowi, że powinien całkowicie przestać akceptować podtrzymania podczas procesu drenażu, byłby jeszcze lepszy, ale o ile wiem, taka funkcja nie istnieje.

Elliott
źródło