Процесс обработки 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 или 1024 слишком мало для производственной среды. Для сайтов с высокой посещаемостью установите значение 2048 или 4096 на каждый рабочий процесс.

Каждому соединению требуется как минимум один файловый дескриптор. В конфигурации обратного прокси каждое соединение использует два (один для клиента, один для сервера). Установите 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_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 буферов по 4 или 8 КБ, всего от 32 до 64 КБ) не вместит большой ответ в формате JSON. Оцените размер вашего самого большого типичного ответа с помощью curl и настройте достаточное количество буферов, чтобы он полностью помещался в ОЗУ.

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

При proxy_buffering on (по умолчанию) Nginx считывает полный ответ из верхнего уровня в память перед отправкой его клиенту. Это позволяет бэкэнд-серверам сразу же переходить к обработке новых запросов.

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

Для конечных точек реального времени, таких как Server-Sent Events или long-polling, отключите буферизацию с помощью proxy_buffering off в блоке, относящемся к конкретному расположению. Применяйте это выборочно к /stream или /events путям, а не глобально.

Балансировка нагрузки и поддержание связи с вышестоящим сервером

По умолчанию 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 слишком малы. Ищите ошибки «too many open files», которые указывают на 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.