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

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?

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ć.

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).

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.

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.