Tuning nginx worker_process w celu uzyskania 100k trafień na minutę


115

Mamy serwer, który obsługuje jeden plik html.

W tej chwili serwer ma 2 procesory i 2 GB pamięci RAM. Z blitz.io uzyskujemy około 12 tys. Połączeń na minutę i gdziekolwiek od 200 limitów czasu w ciągu tych 60 sekund z 250 równoczesnymi połączeniami na sekundę.

worker_processes  2;

events {
 worker_connections 1024;
}

Jeśli zwiększę limit czasu, czas odpowiedzi zacznie wydłużać się powyżej sekundy.

Co jeszcze mogę zrobić, aby wycisnąć z tego więcej soku?

Odpowiedzi:


188

Plik konfiguracyjny:

worker_processes  4;  # 2 * Number of CPUs

events {
    worker_connections  19000;  # It's the key to high performance - have a lot of connections available
}

worker_rlimit_nofile    20000;  # Each connection needs a filehandle (or 2 if you are proxying)


# Total amount of users you can serve = worker_processes * worker_connections

więcej informacji: Optymalizacja nginx pod kątem dużego obciążenia ruchem


14
Myślę, że podane równanie dotyczące całkowitej liczby użytkowników na sekundę jest błędne. Zamiast tego średnia liczba użytkowników obsługiwanych na sekundę powinna wynosić = worker_processes * worker_connections / (keepalive_timeout * 2). Dlatego powyższy plik conf może obsłużyć ~ 7,6 tys. Połączeń na sekundę, czyli znacznie powyżej tego, czego potrzebuje @ablemike. Jednak work_rlimit_nofile jest dobrą dyrektywą do użycia, jeśli ulimit jest restrykcyjny i nie chcesz go modyfikować.
Ethan

2
@Ethan, dlaczego należy go podzielić przez 2? Jeśli w każdej sekundzie otrzymamy 100 nowych połączeń, a limit czasu wynosi 5, to ciąg z szóstą sekundą, będziemy stale mieć 5 * 100 połączeń, które nadal nie są zakończone po stronie serwera. możemy mieć mniej, jeśli niektórzy użytkownicy sami przerywają połączenia
Bulat,

3
ta formuła nie działa, jeśli utrzymywanie aktywności jest ustawione na 0 (wyłączone)
Tilo

5
Każde połączenie wymaga 2 uchwytów plików nawet dla plików statycznych, takich jak obrazy / JS / CSS. To jest 1 dla połączenia klienta i 2 dla otwarcia pliku statycznego. Dlatego bezpieczniej jest zmienić parametr worker_rlimit_nofile = 2 * worker_connections.
Ethan

4
Użyj pliku worker_rlimit_nofile, ale należy również wywołać „ulimit -n”, aby ustawić wartość liczby otwartych plików na proces. Lepiej jest to zrobić w skrypcie startowym.
Ethan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.