Nginx под нагрузкой: как сравнить конфигурации цифрами

Увеличить worker_connections с 1024 до 8192 — не то же самое, что увеличить пропускную способность Nginx в восемь раз. На практике результат ограничивают дескрипторы файлов, число соединений с бэкендом, сеть или сам генератор нагрузки. Поэтому сравнивать конфигурации нужно на одном сервере, с одинаковым запросом и по нескольким метрикам, а не по одному числу запросов в секунду.

Что именно сравниваем

Разбор рассчитан на Nginx 1.26.x и сценарий HTTP reverse proxy: Nginx принимает запросы и передаёт их приложению. Если Nginx раздаёт только статические файлы, ограничения будут другими. Не переносите результаты теста прокси на статический сайт или наоборот.

Сравним два изменения: число соединений на worker и keepalive к upstream. Первое влияет на потолок одновременных клиентских соединений. Второе может сократить повторные TCP-подключения от Nginx к приложению, но не ускорит приложение, которое уже занято обработкой запросов.

Настройка считается быстрее не тогда, когда в конфиге стало больше соединений, а когда при одинаковой нагрузке выросла пропускная способность без неприемлемого роста ошибок и задержки.

Upstream — сервер или группа серверов, куда Nginx передаёт запросы. В этой статье это приложение за прокси.

Какие настройки меняют результат

worker_connections: потолок соединений, а не запросов

Параметр задаёт максимальное число одновременных соединений для одного worker-процесса. Он не равен числу клиентов: при проксировании одно клиентское соединение обычно требует ещё и соединения к upstream. Кроме того, ограничение действует вместе с лимитом файловых дескрипторов процесса. Если дескрипторов не хватает, высокий worker_connections останется цифрой в конфиге.

Консервативная конфигурация может выглядеть так:

worker_processes auto;
worker_connections 1024;

http {
    upstream app_backend {
        server 127.0.0.1:8080;
        keepalive 32;
    }

    server {
        listen 80;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_pass http://app_backend;
        }
    }
}

Значение keepalive здесь — пример исходной настройки, а не рекомендация для любого сервера. В конфигурации с большим числом worker-процессов суммарный пул соединений к upstream может оказаться значительно больше этого числа: лимит применяется отдельно к каждому worker.

Keepalive к приложению: меньше подключений, но больше открытых сокетов

Пул keepalive позволяет повторно использовать соединения с upstream. Это может снизить расходы на установление соединения, особенно если приложение отвечает быстро и запросов много. Обратная сторона — открытые соединения занимают ресурсы Nginx и приложения. Настройка не помогает, если upstream не поддерживает ожидаемое поведение или запросы надолго занимают его соединения.

Для честного сравнения меняйте только размер пула, оставляя прочие условия прежними:

upstream app_backend {
    server 127.0.0.1:8080;
    keepalive 64;
}

Перед тестом проверьте официальную документацию и конфигурацию конкретного приложения: поддержка повторного использования соединений и ограничения на их число зависят от upstream. Если вместе с keepalive вы поменяете число worker-процессов, лимиты приложения и формат ответа, понять причину результата будет сложнее.

Как получить сравнимые цифры

В исходных материалах нет замеров для конкретного железа, версии ОС, приложения и тестового профиля. Поэтому приводить «рост на 40%» было бы выдумкой. Ниже — схема измерения, которая даст ваши цифры и поможет отделить эффект настройки от шума.

1. Зафиксируйте стенд. Запишите версию Nginx, модель CPU, число ядер, объём памяти, ОС и место запуска генератора нагрузки. Если генератор работает на той же машине, он сам может стать ограничением. Проверка: для каждого прогона известны одинаковые исходные условия.
2. Определите один сценарий. Выберите URL, метод, размер ответа, долю кеширования и профиль длительности. Не смешивайте статические файлы, динамические страницы и загрузку больших тел запросов в одном сравнении. Проверка: каждый вариант конфигурации получает одинаковый набор запросов.
3. Снимите базовый результат. Запустите нагрузку на исходном конфиге, затем сохраните число запросов в секунду, медиану и 95-й перцентиль задержки, долю ошибок и загрузку CPU. Проверка: лог нагрузки и системные метрики относятся к одному временному интервалу.
4. Меняйте один параметр. Например, сравните worker_connections 1024 и 4096, не меняя keepalive и бэкенд. Перед перезапуском проверьте конфигурацию штатной командой nginx -t. Проверка: команда сообщает, что конфигурация синтаксически корректна.
5. Повторите каждый прогон. Выполните несколько повторов, чередуя порядок вариантов, и сравните медианные результаты. Проверка: вывод не зависит от одного удачного или неудачного запуска.

В таблицу результатов заносите не только RPS. Удобный набор: конфигурация, запросы в секунду, p50 и p95 задержки, доля ошибок, CPU Nginx и CPU приложения, максимальное число открытых дескрипторов. p95 показывает задержку, быстрее которой завершились 95% запросов; среднее значение может скрыть медленный хвост.

Что ломается первым

Рост RPS при одновременно растущем p95 — не обязательно победа. Клиенты получают больше быстрых ответов, но часть запросов начинает ждать слишком долго. Если увеличилась доля ошибок, проверьте журналы Nginx и приложения, системные лимиты и состояние генератора нагрузки. Ошибки 502 и 504 могут указывать на проблемы взаимодействия с upstream, но сами по себе не доказывают, что виноват конкретный параметр Nginx.

Особенно опасно масштабировать keepalive без проверки лимитов приложения: пул умножается на число worker-процессов, а бэкенд может получить больше одновременно открытых соединений, чем ожидает. Аналогично, высокий worker_connections не отменяет ограничения файловых дескрипторов. Следите за фактическим числом соединений и сообщениями об ошибках, а не только за значением в конфиге.

Где сравнение перестаёт быть честным

Результат нельзя переносить на другую нагрузку, если изменились размер ответа, доля кеш-хитов, география клиента или профиль параллельности. Нельзя также делать вывод по тесту, где приложение прогрелось только для одного варианта. Для корректного сравнения прогревайте стенд одинаково, фиксируйте состояние кеша и повторяйте тесты.

Если цель — проверить предел системы, постепенно повышайте параллельность и отмечайте момент, когда ошибки или p95 начинают расти быстрее пропускной способности. Если цель — проверить ожидаемую повседневную нагрузку, тестируйте именно её профиль: искусственный максимум может выявить другой bottleneck и привести к ненужному усложнению конфигурации.

Что делать дальше

Сначала снимите базовый профиль и найдите ограничение: CPU, файловые дескрипторы, сеть, диск или время ответа upstream. Затем меняйте один параметр и повторяйте тот же сценарий. В проде наблюдайте за p95 задержки, долей ошибок, активными соединениями и ресурсами приложения: если выигрыш на тестовом стенде сопровождается ухудшением этих показателей, конфигурация не стала лучше.