Przebieg przetwarzania HTTP w Nginx: dostosowywanie konfiguracji

Domyślna konfiguracja Nginx została zaprojektowana z myślą o kompatybilności, a nie o wydajności. Dzięki odpowiedniemu dostrojeniu pojedynczy serwer może obsłużyć od 50 000 do 80 000 żądań na sekundę. Niniejszy przewodnik obejmuje najważniejsze ustawienia: procesy robocze, połączenia, keepalive, buforowanie, równoważenie obciążenia oraz sposób weryfikacji zmian za pomocą testów porównawczych.

Jak Nginx przetwarza żądania HTTP

Nginx obsługuje żądania w odrębnych fazach, z których każda zużywa zasoby systemowe. Zrozumienie tego przepływu pomaga w doborze odpowiednich ustawień.

Proces rozpoczyna się na poziomie jądra. Przychodzące połączenia trafiają do kolejek SYN i ACCEPT, a procesy robocze Nginx je odbierają. Po zaakceptowaniu żądania proces roboczy analizuje żądanie HTTP z bufora jądra. Ruch TLS sprawia, że ten etap jest bardziej obciążający dla procesora.

Następnie Nginx dopasowuje żądanie do serwera wirtualnego, korzystając z nagłówka Host oraz kombinacji adresu IP i portu, a następnie rozpoznaje adres URI jako blok lokalizacji poprzez dopasowanie prefiksu lub wyrażenia regularnego.

W przypadku treści dynamicznych Nginx przekazuje żądanie do zaplecza (FastCGI, proxy). Ta faza komunikacji upstream czerpie ogromne korzyści z połączeń trwałych. Bez funkcji keepalive upstream Nginx otwiera nowe połączenie TCP dla każdego żądania, co zwiększa opóźnienia i obciążenie procesora.

Jeśli proxy_buffering jest włączona, Nginx wczytuje pełną odpowiedź upstream do pamięci przed dostarczeniem jej do klienta. To pozwala procesowi roboczemu natychmiast obsłużyć nowe żądania. Wreszcie, podczas dostarczania danych wyjściowych, włączenie sendfile umożliwia transfery typu zero-copy, co może zwiększyć przepustowość z około 6 Gb/s do 30 Gb/s.

Każda faza zużywa bufory pamięci, deskryptory plików i cykle procesora. Poniższe sekcje dotyczą poszczególnych wąskich gardeł.

Procesy robocze i połączenia

Zacznij od worker_processes auto; w głównym kontekście. Spowoduje to dopasowanie liczby procesów roboczych do rdzeni procesora. Na serwerze VPS z ograniczoną liczbą rdzeni ustaw liczbę ręcznie (np. worker_processes 2;). Jeśli obciążenie wymaga dużej ilości pamięci, rozważ zmniejszenie liczby procesów roboczych, aby uniknąć nadmiernego obciążenia pamięci RAM.

Włącz worker_cpu_affinity auto; , aby przypisać każdego pracownika do konkretnego rdzenia. Zmniejsza to liczbę nieudanych operacji pamięci podręcznej i przełączania kontekstu. Dostępne od wersji Nginx 1.9.10.

Limity połączeń

Dyrektywa worker_connections określa, ile jednoczesnych połączeń może obsłużyć każdy procesor. Całkowita pojemność wynosi worker_processes × worker_connections. Domyślna wartość 512 lub 1024 jest zbyt niska dla środowiska produkcyjnego. W przypadku witryn o dużym natężeniu ruchu należy ustawić ją na 2048 lub 4096 na proces roboczy.

Każde połączenie wymaga co najmniej jednego deskryptora pliku. W konfiguracji odwrotnego proxy każde połączenie wykorzystuje dwa (jeden dla klienta, jeden dla serwera źródłowego). Ustaw worker_rlimit_nofile wartość co najmniej dwukrotnie większą od worker_connections wartość z zapasem. W przypadku worker_connections 4096;, użyj worker_rlimit_nofile 10000; lub wyższą

Na poziomie systemu zwiększ fs.file-max wartość /etc/sysctl.conf do co najmniej 500 000 i ustaw LimitNOFILE=65535.

Na koniec dodaj multi_accept on; w bloku events, aby procesy worker akceptowały wszystkie oczekujące połączenia naraz, a nie pojedynczo.

Limity czasu i keepalive

Keepalive klienta

Dyrektywa keepalive_timeout kontroleruje, jak długo pozostają otwarte nieaktywne połączenia klienckie. W przypadku serwerów o dużym natężeniu ruchu dobrze sprawdza się wartość od 30 do 65 sekund. Należy użyć formy z dwoma parametrami:

keepalive_timeout 65s 60s;

Pierwsza wartość to limit czasu po stronie serwera. Druga wysyła Keep-Alive: timeout=60 nagłówek do klienta. Ustawienie wartości po stronie klienta na nieco niższy poziom zapobiega sytuacjom wyścigu, w których przeglądarki próbują ponownie wykorzystać połączenia, które Nginx już zamknął.

Dyrektywa keepalive_requests Ogranicza liczbę żądań, które obsługuje pojedyncze połączenie przed jego zamknięciem. Wartość domyślna to 1000 (zwiększona ze 100 w wersji 1.19.10). W przypadku stabilnych backendów warto zwiększyć tę wartość do 10 000, aby zmniejszyć częstotliwość zamykania i ponownego nawiązywania połączeń.

Limity czasu proxy

proxy_connect_timeout określa, jak długo Nginx czeka na nawiązanie połączenia z backendem. Domyślnie jest to 60 sekund. Zmniejsz tę wartość do 5–10 sekund, aby zapewnić szybkie przełączanie awaryjne.

proxy_read_timeout określa, jak długo Nginx czeka między kolejnymi odczytami z upstreamu. Dostosuj tę wartość do limitu czasu wykonania twojego backendu. Jeśli limit czasu PHP-FPM request_terminate_timeout wynosi 120 sekund, ustaw proxy_read_timeout co najmniej 120 sekund, aby uniknąć przedwczesnych błędów 504.

proxy_send_timeout kontroluje odstęp czasu między kolejnymi zapisami do serwera upstream. Domyślne 60 sekund zazwyczaj wystarcza, chyba że wysyłasz duże treści żądań.

Z reguły proxy_connect_timeout powinien być zawsze najkrótszy z tych trzech.

Rozmiar bufora

client_body_buffer_size określa, jaką część treści przychodzącego żądania Nginx przechowuje w pamięci. Domyślna wartość 8k lub 16k obsługuje proste przesłania formularzy, ale przesyłanie plików spowoduje zapełnienie dysku. Zwiększ ją do 128k dla małych i średnich plików. Zwiększ client_max_body_size wartość domyślną 1 MB, jeśli użytkownicy przesyłają większe pliki.

proxy_buffer_size obsługuje nagłówki odpowiedzi oddzielnie od treści. Domyślne wartości 4k lub 8k zazwyczaj działają, ale aplikacje z dużymi Set-Cookie nagłówkami (często spotykane w e-commerce) mogą przekroczyć ten limit, powodując błędy 502. Zmierz rzeczywisty rozmiar nagłówka:

curl -s -w '%{size_header}' -o /dev/null http://your-upstream-url

Zaokrąglij w górę do najbliższego wielokrotności 4k.

proxy_buffers ustawia liczbę i rozmiar buforów dla treści odpowiedzi. Ustawienie domyślne (8 buforów o rozmiarze 4 kB lub 8 kB, łącznie od 32 kB do 64 kB) nie pomieści dużej odpowiedzi JSON. Zmierz swoją największą typową odpowiedź przy curl i skonfiguruj wystarczającą liczbę buforów, aby zmieściła się ona w całości w pamięci RAM.

Zachowanie buforowania proxy

Przy proxy_buffering on (ustawienie domyślne) Nginx wczytuje pełną odpowiedź z serwera źródłowego do pamięci przed wysłaniem jej do klienta. Pozwala to serwerom zaplecza natychmiast przejść do obsługi nowych żądań.

Ustaw proxy_busy_buffers_size co najmniej proxy_buffer_size plus jeden bufor, ale mniej niż całkowita pula buforów. W przypadku proxy_buffers 8 16k (łącznie 128k) należy utrzymać proxy_busy_buffers_size poniżej 112k.

W przypadku punktów końcowych działających w czasie rzeczywistym, takich jak zdarzenia wysyłane przez serwer (Server-Sent Events) lub długie odpytywanie (long-polling), wyłącz buforowanie za pomocą proxy_buffering off w bloku specyficznym dla danej lokalizacji. Zastosuj to selektywnie do /stream lub /events ścieżki, a nie globalnie.

Równoważenie obciążenia i utrzymywanie połączenia upstream

Domyślnie Nginx otwiera nowe połączenie TCP dla każdego żądania proxy. Każde nawiązanie połączenia powoduje opóźnienie od 10 do 100 ms, a TLS dodaje kolejne 10 do 50 ms. Upstream keepalive utrzymuje pulę trwałych połączeń, aby wyeliminować to obciążenie.

Wymagane są trzy ustawienia:

upstream backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    keepalive 128;
}
 
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Wartość keepalive wartość określa maksymalną liczbę nieaktywnych połączeń na pracownika. Oblicz optymalny rozmiar puli jako: (workers × target concurrency) / upstream nodes.

Ustaw upstream keepalive_timeout na 60 do 120 sekund, aby dopasować go do ustawień serwera docelowego i obsłużyć skoki ruchu.

Strategie równoważenia obciążenia

Nginx obsługuje kilka metod równoważenia obciążenia. Round-robin (domyślnie) rozdziela żądania sekwencyjnie. least_conn kieruje do serwera z najmniejszą liczbą aktywnych połączeń, co sprawdza się w przypadku obciążeń o zmiennym czasie trwania żądań. ip_hash zapewnia trwałość sesji poprzez kierowanie tego samego adresu IP klienta do tego samego serwera zaplecza.

Użyj parametru weight , gdy serwery mają różną przepustowość:

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080 backup;
    keepalive 128;
}

Serwer ważony odbiera trzykrotnie większy ruch. Serwer backup serwer aktywuje się tylko wtedy, gdy wszystkie serwery podstawowe są wyłączone. Skonfiguruj max_fails i fail_timeout do pasywnych testów sprawności oraz użyj max_conns , aby ograniczyć liczbę jednoczesnych połączeń na backend.

Testowanie i monitorowanie

Zawsze mierz wydajność bazową przed wprowadzeniem jakichkolwiek zmian. Po każdej zmianie przeprowadź ponowny test porównawczy. Wprowadzaj zmiany pojedynczo.

Zweryfikuj składnię konfiguracji za pomocą nginx -t przed ponownym załadowaniem. Uruchom testy porównawcze z oddzielnego komputera, aby uniknąć konfliktu o zasoby.

wrk jest standardowym narzędziem do testowania obciążenia HTTP:

wrk -t4 -c200 -d30s http://your-server.com/

Śledź liczbę żądań na sekundę, średnie opóźnienie, maksymalne opóźnienie i szybkość transferu. Apache Bench sprawdza się w przypadku prostszych testów:

ab -n 50000 -c 40 http://your-server.com/

Bieżące monitorowanie

Włącz moduł stub_status moduł, aby monitorować aktywne połączenia w czasie rzeczywistym za pomocą curl http://localhost/nginx_status.

Dodaj zmienne czasowe do formatu logów, aby zidentyfikować miejsca występowania opóźnień:

• $request_time dla całkowitego czasu trwania żądania
• $upstream_connect_time dla czasu połączenia z zapleczem
• $upstream_response_time dla całkowitego czasu przetwarzania na serwerze

Sprawdź logi błędów pod kątem problemów z buforem przy journalctl -u nginx --no-pager | grep "temporary file". Jeśli odpowiedzi trafiają na dysk, oznacza to, że proxy_buffers są zbyt małe. Poszukaj błędów „zbyt wiele otwartych plików”, które wskazują worker_rlimit_nofile należy zwiększyć.

Zmniejsz operacje wejścia/wyjścia dziennika dzięki buforowanemu logowaniu:

access_log /var/log/nginx/access.log combined buffer=64k flush=5s;

Użyj ss -tn state established dst [backend_ip] podczas testów obciążeniowych, aby sprawdzić, czy połączenia są ponownie wykorzystywane i nie gromadzą się w stanie TIME_WAIT.

W przypadku serwerów dedykowanych i hostingu VPS zoptymalizowanych pod kątem obciążeń o wysokiej wydajności zobacz serwery FDC.