Процес обробки HTTP в Nginx: налаштування конфігурації

Стандартна конфігурація Nginx розроблена з урахуванням сумісності, а не продуктивності. При правильному налаштуванні один сервер може обробляти від 50 000 до 80 000 запитів на секунду. Цей посібник охоплює найважливіші налаштування: робочі процеси, з'єднання, keepalive, буферизацію, балансування навантаження, а також способи перевірки змін за допомогою тестів продуктивності.

Як Nginx обробляє HTTP-запити

Nginx обробляє запити в окремих фазах, кожна з яких споживає системні ресурси. Розуміння цього процесу допоможе вам обрати правильні налаштування.

Процес починається на рівні ядра. Вхідні з'єднання потрапляють у черги SYN та ACCEPT, і робочі процеси Nginx їх підхоплюють. Після прийняття запиту робочий процес аналізує HTTP-запит із буфера ядра. Трафік TLS робить цей крок більш ресурсоємним для процесора.

Далі Nginx зіставляє запит із віртуальним сервером, використовуючи заголовок Host та комбінацію IP/порт, а потім вирішує URI у блок розташування за допомогою префікса або співпадіння регулярного виразу.

Для динамічного контенту Nginx пересилає запит на бекенд (FastCGI, проксі). Ця фаза комунікації з бекендом значною мірою виграє від постійних з'єднань. Без keepalive з бекендом Nginx відкриває нове TCP-з'єднання для кожного запиту, що збільшує затримку та навантаження на процесор.

Якщо proxy_buffering увімкнено, Nginx зчитує повну відповідь вищого рівня в пам'ять перед тим, як передати її клієнту. Це звільняє робочий процес для негайної обробки нових запитів. Нарешті, під час передачі вихідних даних увімкнення sendfile дозволяє здійснювати передачу без копіювання, що може збільшити пропускну здатність з приблизно 6 Гбіт/с до 30 Гбіт/с.

Кожна фаза споживає буфери пам'яті, дескриптори файлів та цикли процесора. Наведені нижче розділи присвячені кожному з цих вузьких місць.

Робочі процеси та з’єднання

Почніть з worker_processes auto; у вашому основному контексті. Це узгоджує кількість робочих процесів із вашими ядрами процесора. На VPS з обмеженою кількістю ядер встановіть кількість вручну (наприклад, worker_processes 2;). Якщо ваше навантаження є ресурсоємним щодо пам’яті, розгляньте можливість зменшення кількості робочих процесів, щоб уникнути перевантаження оперативної пам’яті.

Увімкніть worker_cpu_affinity auto; , щоб прив'язати кожен робочий процес до конкретного ядра. Це зменшує кількість промахів кешу та перемикання контексту. Доступно починаючи з Nginx 1.9.10.

Обмеження підключень

Директива worker_connections директива встановлює, скільки одночасних з'єднань може обробляти кожен робочий процес. Загальна пропускна здатність становить worker_processes × worker_connections. Значення за замовчуванням 512 або 1 024 є занадто низьким для виробничого середовища. Для сайтів з високим трафіком встановіть його на 2 048 або 4 096 на кожен робочий процес.

Кожне з'єднання потребує принаймні одного файлового дескриптора. У конфігурації зворотного проксі-сервера кожне з'єднання використовує два (один для клієнта, один для вищого рівня). Встановіть worker_rlimit_nofile значення, що принаймні вдвічі перевищує worker_connections значення з запасом. Для worker_connections 4096;, використовуйте worker_rlimit_nofile 10000; або вище.

На системному рівні збільште fs.file-max значення /etc/sysctl.conf щонайменше до 500 000 та встановіть LimitNOFILE=65535.

Нарешті, додайте multi_accept on; у блок events, щоб робочі процеси приймали всі очікувані з'єднання одразу, а не по одному.

Тайм-аути та Keepalive

Keepalive клієнта

Директива keepalive_timeout директива контролює, як довго залишаються відкритими неактивні клієнтські з'єднання. Для серверів з високим трафіком добре підходить час від 30 до 65 секунд. Використовуйте форму з двома параметрами:

keepalive_timeout 65s 60s;

Перше значення — це тайм-аут на стороні сервера. Друге — надсилає Keep-Alive: timeout=60 заголовок клієнту. Встановлення значення для клієнта трохи нижчим запобігає гонці умов, коли браузери намагаються повторно використати з'єднання, які Nginx вже закрив.

Директива keepalive_requests директива обмежує кількість запитів, які обробляє одне з'єднання, перш ніж воно буде закрите. За замовчуванням встановлено 1 000 (збільшено з 100 у версії 1.19.10). Для стабільних серверів обробки даних збільште це значення до 10 000, щоб зменшити частоту закриття з'єднань.

Тайм-аути проксі

proxy_connect_timeout визначає, скільки часу Nginx чекає на встановлення з'єднання з бекендом. За замовчуванням — 60 секунд. Зменшіть це значення до 5–10 секунд для швидкого переключення на резерв.

proxy_read_timeout визначає, скільки часу Nginx чекає між послідовними читаннями з upstream. Узгодьте це з тайм-аутом виконання вашого бекенду. Якщо для PHP-FPM request_terminate_timeout становить 120 секунд, встановіть proxy_read_timeout щонайменше 120 секунд, щоб уникнути передчасних помилок 504.

proxy_send_timeout регулює інтервал між послідовними записами на сервер. Значення за замовчуванням — 60 секунд — зазвичай підходить, якщо ви не надсилаєте великі тіла запитів.

Як правило, proxy_connect_timeout завжди має бути найкоротшим із трьох.

Розмір буфера

client_body_buffer_size визначає, яку частину тіла вхідного запиту Nginx зберігає в пам'яті. Значення за замовчуванням 8k або 16k дозволяє обробляти прості форми, але завантаження файлів буде зберігатися на диску. Збільште його до 128k для завантажень невеликого та середнього розміру. Збільште client_max_body_size значення за замовчуванням 1 Мб, якщо користувачі завантажують великі файли.

proxy_buffer_size обробляє заголовки відповіді окремо від тіла. Значення за замовчуванням 4k або 8k зазвичай працює, але додатки з великими Set-Cookie заголовками (що часто зустрічається в електронній комерції) можуть перевищити це значення, викликаючи помилки 502. Виміряйте фактичний розмір ваших заголовків:

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

округляйте до найближчого кроку в 4k.

proxy_buffers визначає кількість і розмір буферів для тіла відповіді. Значення за замовчуванням (8 буферів по 4k або 8k, загалом від 32k до 64k) не вмістить велику відповідь у форматі JSON. Виміряйте свою найбільшу типову відповідь за допомогою curl і налаштуйте достатню кількість буферів, щоб повністю вмістити його в оперативній пам'яті.

Поведінка буферизації проксі

З proxy_buffering on (за замовчуванням) Nginx зчитує повну відповідь з вищого рівня в пам'ять перед тим, як надіслати її клієнту. Це дозволяє серверам бекенду негайно переходити до нових запитів.

Встановіть proxy_busy_buffers_size на значення не менше proxy_buffer_size плюс один буфер, але менше, ніж ваш загальний пул буферів. Для proxy_buffers 8 16k (загалом 128k) тримайте proxy_busy_buffers_size менше 112k.

Для кінцевих точок реального часу, таких як події, надіслані сервером, або тривалий опитування, вимкніть буферизацію за допомогою proxy_buffering off у блоці, що стосується конкретного місця. Застосовуйте це вибірково до /stream або /events шляхи, а не глобально.

Балансування навантаження та Upstream Keepalive

За замовчуванням Nginx відкриває нове TCP-з'єднання для кожного проксі-запиту. Кожен рукостискання додає від 10 до 100 мс затримки, а TLS додає ще від 10 до 50 мс. Upstream keepalive підтримує пул постійних з'єднань, щоб усунути ці накладні витрати.

Потрібні три налаштування:

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 "";
    }
}

Параметр keepalive значення встановлює максимальну кількість неактивних з'єднань на одного працівника. Розрахуйте оптимальний розмір пулу за формулою: (workers × target concurrency) / upstream nodes.

Встановіть keepalive_timeout на 60–120 секунд, щоб відповідати налаштуванням вашого бекенду та обробляти піки трафіку.

Стратегії балансування

Nginx підтримує кілька методів балансування навантаження. Round-robin (за замовчуванням) розподіляє запити послідовно. least_conn направляє запити на сервер з найменшою кількістю активних з'єднань, що підходить для робочих навантажень із змінною тривалістю запитів. ip_hash забезпечує збереження сеансу, маршрутизуючи IP-адресу одного й того ж клієнта до одного й того ж бекенду.

Використовуйте параметр weight параметр, коли сервери мають різну пропускну здатність:

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;
}

Сервер з вагою отримує втричі більше трафіку. Сервер backup сервер активується лише тоді, коли всі основні сервери не працюють. Налаштуйте max_fails та fail_timeout для пасивних перевірок працездатності та використовуйте max_conns для обмеження кількості одночасних підключень на кожен бекенд.

Тестування та моніторинг

Завжди вимірюйте базову продуктивність перед тим, як щось змінювати. Після кожної зміни проводьте повторне тестування. Вносьте зміни по одній за раз.

Перевірте синтаксис конфігурації за допомогою nginx -t перед перезавантаженням. Виконуйте тестування з окремого комп'ютера, щоб уникнути конфлікту ресурсів.

wrk — це стандартний інструмент для тестування навантаження HTTP:

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

Відстежуйте кількість запитів на секунду, середню затримку, максимальну затримку та швидкість передачі даних. Apache Bench підходить для простіших тестів:

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

Постійний моніторинг

Увімкніть модуль stub_status модуль для моніторингу активних з'єднань у реальному часі за допомогою curl http://localhost/nginx_status.

Додайте змінні часу до формату вашого журналу, щоб визначити, де відбуваються затримки:

• $request_time для загальної тривалості запиту
• $upstream_connect_time для часу з'єднання з сервером
• $upstream_response_time для загального часу обробки бекендом

Перевірте журнали помилок на наявність проблем із буфером за допомогою journalctl -u nginx --no-pager | grep "temporary file". Якщо відповіді записуються на диск, ваші proxy_buffers занадто малі. Шукайте помилки «занадто багато відкритих файлів», які вказують на worker_rlimit_nofile необхідність збільшення.

Зменшіть введення-виведення журналу за допомогою буферованого ведення журналу:

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

Використовуйте ss -tn state established dst [backend_ip] під час навантажувальних тестів, щоб перевірити, чи з'єднання повторно використовуються і не накопичуються в TIME_WAIT.

Щодо виділених серверів та VPS-хостингу, оптимізованих для високопродуктивних робочих навантажень, див. FDC Servers.