Основной контрольный список для настройки производительности Nginx на высоконагруженных веб-сайтах

Для любого веб-сайта, испытывающего значительный трафик, Nginx является мощным и высокоэффективным веб-сервером и обратным прокси. Однако простого развертывания Nginx недостаточно, чтобы гарантировать оптимальную производительность при высокой нагрузке. Правильная конфигурация и настройка критически важны для раскрытия его полного потенциала, обеспечивая быструю, отзывчивую и надежную работу ваших веб-приложений.

Эта статья представляет собой исчерпывающий контрольный список ключевых конфигураций и директив Nginx, специально разработанных для оптимизации производительности в условиях высокой нагрузки. Мы рассмотрим все: от управления рабочими процессами и соединениями до тонкой настройки буферов, реализации надежных стратегий кэширования и оптимизации сжатия. Систематически решая эти задачи, вы сможете значительно снизить нагрузку на сервер, повысить скорость доставки контента и улучшить общий пользовательский опыт.

1. Оптимизация рабочих процессов и соединений

Nginx использует модель главный-рабочий процесс. Главный процесс читает конфигурацию и управляет рабочими процессами, которые обрабатывают фактические клиентские запросы. Правильная настройка этих процессов может значительно улучшить параллелизм и использование ресурсов.

worker_processes

Эта директива определяет, сколько рабочих процессов Nginx будет создавать. Обычно установка значения auto позволяет Nginx автоматически определять количество ядер CPU и запускать равное количество рабочих процессов, что является распространенной лучшей практикой.

worker_connections

Определяет максимальное количество одновременных соединений, которые может открыть один рабочий процесс. Этот параметр, в сочетании с worker_processes, определяет общее теоретическое количество одновременных соединений, которое Nginx может обработать (worker_processes * worker_connections).

multi_accept

Позволяет рабочему процессу принимать несколько новых соединений одновременно, предотвращая потенциальные узкие места при высокой нагрузке.

# /etc/nginx/nginx.conf

worker_processes auto; # Обычно устанавливается 'auto' или количество ядер CPU

events {
    worker_connections 1024; # Настраивается исходя из мощности сервера и ожидаемой нагрузки
    multi_accept on;
}

Совет: Отслеживайте загрузку CPU вашего сервера. Если worker_processes установлен в auto, и загрузка CPU постоянно высока, возможно, стоит увеличить worker_connections или масштабировать ресурсы вашего сервера.

2. Эффективное управление соединениями

Оптимизация того, как Nginx обрабатывает сетевые соединения, может снизить накладные расходы и улучшить отзывчивость.

keepalive_timeout

Указывает, как долго клиентское соединение keep-alive будет оставаться открытым. Повторное использование соединений уменьшает накладные расходы на установление новых TCP-соединений и SSL-рукопожатий. Распространенное значение составляет 15-65 секунд, в зависимости от интерактивности вашего приложения.

sendfile

Включает прямую передачу данных между файловыми дескрипторами, минуя буферизацию в пользовательском пространстве. Это значительно улучшает производительность при отдаче статических файлов.

tcp_nopush

Работает совместно с sendfile. Nginx пытается отправить HTTP-заголовок и начало файла в одном пакете. После этого он отправляет данные полными пакетами. Это уменьшает количество отправляемых пакетов.

tcp_nodelay

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

http {
    keepalive_timeout 65; # Keep-alive соединения в течение 65 секунд
    sendfile on;
    tcp_nopush on; # Требует sendfile on
    tcp_nodelay on; # Полезно для проксирования динамического контента
}

3. Оптимизация буферов

Nginx использует буферы для обработки клиентских запросов и ответов от вышестоящих серверов (таких как серверы приложений). Правильный размер этих буферов может предотвратить ненужный дисковый I/O, уменьшить использование памяти и повысить пропускную способность.

Клиентские буферы

• client_body_buffer_size: Размер буфера для тел клиентских запросов. Если тело превышает этот размер, оно записывается во временный файл.
• client_header_buffer_size: Размер буфера для первой строки и заголовков клиентского запроса.
• large_client_header_buffers: Определяет количество и размер больших буферов для чтения заголовков клиентских запросов. Полезно для запросов с большим количеством cookies или длинными заголовками referer.

Прокси-буферы (для настроек обратного прокси)

• proxy_buffers: Количество и размер буферов, используемых для чтения ответов от проксируемого сервера.
• proxy_buffer_size: Размер первого буфера для чтения ответа. Обычно меньше, так как часто содержит только заголовки.
• proxy_busy_buffers_size: Максимальный объем буферов ответа, которые могут находиться в состоянии 'busy' (активно отправляются клиенту) в любой момент времени.

FastCGI-буферы (для PHP-FPM и т.д.)

• fastcgi_buffers: Количество и размер буферов, используемых для чтения ответов от FastCGI-сервера.
• fastcgi_buffer_size: Размер первого буфера для чтения ответа.

http {
    # Клиентские буферы
    client_body_buffer_size 1M; # Настраивается исходя из ожидаемого размера тела запроса (например, загрузки файлов)
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k; # 4 буфера, каждый размером 8 КБ

    # Прокси-буферы (если Nginx действует как обратный прокси)
    proxy_buffers 8 16k; # 8 буферов, каждый 16 КБ
    proxy_buffer_size 16k; # Первый буфер 16 КБ
    proxy_busy_buffers_size 16k; # Максимум 16 КБ занятых буферов

    # FastCGI-буферы (если Nginx работает с PHP-FPM)
    fastcgi_buffers 116 8k; # 116 буферов, каждый 8 КБ (например, для WordPress)
    fastcgi_buffer_size 16k; # Первый буфер 16 КБ
}

Предупреждение: Слишком маленькие буферы могут привести к дисковому I/O и снижению производительности. Слишком большие буферы могут потреблять избыточную память. Найдите баланс путем тестирования.

4. Внедрение надежных стратегий кэширования

Кэширование — один из наиболее эффективных способов улучшить производительность и снизить нагрузку на ваши серверы бэкэнда. Nginx может служить мощным кэшем контента.

proxy_cache_path

Определяет путь к каталогу кэша, его размер, количество уровней подкаталогов и время, в течение которого неактивные элементы остаются в кэше.

proxy_cache

Активирует кэширование для данного блока location, ссылаясь на зону, определенную в proxy_cache_path.

proxy_cache_valid

Устанавливает время, в течение которого Nginx должен кэшировать ответы с определенными HTTP-статусами.

proxy_cache_revalidate

Когда включено, Nginx будет использовать заголовки If-Modified-Since и If-None-Match для повторной проверки кэшированного контента с бэкэндом, уменьшая использование пропускной способности.

proxy_cache_use_stale

Предписывает Nginx отдавать устаревший кэшированный контент, если бэкэнд-сервер не работает, не отвечает или испытывает ошибки. Это значительно улучшает доступность.

expires

Устанавливает заголовки Cache-Control и Expires для клиентского кэширования статических файлов. Это минимизирует повторные запросы к Nginx.

http {
    # Определите зону прокси-кэша в блоке http
    proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=10g;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_upstream_backend;
            proxy_cache my_cache; # Включить кэширование для этого location
            proxy_cache_valid 200 302 10m; # Кэшировать успешные ответы на 10 минут
            proxy_cache_valid 404 1m; # Кэшировать 404-е ответы на 1 минуту
            proxy_cache_revalidate on;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X-Cache-Status $upstream_cache_status; # Помогает при отладке
        }

        # Кэшировать статические файлы в браузере на более длительный период
        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            expires 30d; # Кэшировать на 30 дней
            add_header Cache-Control "public, no-transform";
            # Для статических файлов рассмотрите возможность отдачи напрямую из Nginx, если они не проксируются
            root /var/www/html;
        }
    }
}

5. Включение Gzip-сжатия

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

gzip on

Активирует gzip-сжатие.

gzip_comp_level

Устанавливает уровень сжатия (1-9). Уровень 1 самый быстрый с меньшим сжатием; Уровень 9 самый медленный с максимальным сжатием. Уровень 6 обычно обеспечивает хороший баланс.

gzip_types

Указывает MIME-типы, которые должны быть сжаты. Включите общие текстовые, CSS, JavaScript и JSON-типы.

gzip_min_length

Устанавливает минимальную длину ответа (в байтах), для которой должно быть включено сжатие. Маленькие файлы мало выигрывают и могут быть даже медленнее из-за накладных расходов на сжатие.

gzip_proxied

Предписывает Nginx сжимать ответы, даже если они проксируются. any — это распространенное значение.

gzip_vary

Добавляет заголовок Vary: Accept-Encoding к ответам, информируя прокси о том, что ответ может отличаться в зависимости от заголовка запроса Accept-Encoding.

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6; # Уровень сжатия 1-9 (6 - хороший баланс)
    gzip_buffers 16 8k; # 16 буферов, каждый 8 КБ
    gzip_http_version 1.1; # Минимальная HTTP-версия для сжатия
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
    gzip_min_length 1000; # Сжимать только ответы размером более 1 КБ
}

6. Оптимизация логирования

Хотя логи необходимы для мониторинга и устранения неполадок, избыточное или неоптимизированное логирование может привести к значительному дисковому I/O, особенно на высоконагруженных сайтах.

access_log

• Отключение для статических ресурсов: Для часто запрашиваемого статического контента (изображения, CSS, JS) отключение access_log может сэкономить много I/O.
• Буферизация: Nginx может буферизировать записи логов в памяти, прежде чем записывать их на диск, уменьшая частоту записи на диск. Здесь используются параметры buffer и flush.

error_log

Установите соответствующий уровень логирования (crit, error, warn, info, debug). Для продакшена обычно достаточно warn или error, чтобы фиксировать критические проблемы без переполнения логов.

http {
    server {
        # Журнал доступа по умолчанию для динамического контента
        access_log /var/log/nginx/access.log main;

        location ~* \.(jpg|jpeg|gif|png|css|js|ico|woff|woff2|ttf|svg|eot)$ {
            access_log off; # Отключить логирование для общих статических файлов
            expires 30d;
        }
    }

    # Пример буферизированного журнала доступа для основного HTTP-контекста
    # access_log /var/log/nginx/access.log main buffer=16k flush=5s;
    error_log /var/log/nginx/error.log warn; # Логировать только предупреждения и выше
}

7. Настройка таймаутов

Правильно настроенные таймауты предотвращают слишком долгое удержание Nginx неактивных соединений, освобождая ресурсы.

Таймауты на стороне клиента

• client_body_timeout: Как долго Nginx ожидает от клиента отправки тела запроса.
• client_header_timeout: Как долго Nginx ожидает от клиента отправки заголовка запроса.
• send_timeout: Как долго Nginx ожидает, пока клиент примет ответ после его отправки.

Таймауты прокси/FastCGI (если применимо)

• proxy_connect_timeout: Таймаут для установления соединения с проксируемым сервером.
• proxy_send_timeout: Таймаут для передачи запроса проксируемому серверу.
• proxy_read_timeout: Таймаут для чтения ответа от проксируемого сервера.

http {
    client_body_timeout 15s; # У клиента есть 15 секунд на отправку тела
    client_header_timeout 15s; # У клиента есть 15 секунд на отправку заголовков
    send_timeout 15s; # У Nginx есть 15 секунд на отправку ответа клиенту

    # Для сценариев прокси
    proxy_connect_timeout 5s; # 5 секунд для подключения к вышестоящему серверу
    proxy_send_timeout 15s; # 15 секунд для отправки запроса вышестоящему серверу
    proxy_read_timeout 15s; # 15 секунд для чтения ответа от вышестоящего сервера

    # Для сценариев FastCGI
    fastcgi_connect_timeout 5s;
    fastcgi_send_timeout 15s;
    fastcgi_read_timeout 15s;
}

8. Оптимизация SSL/TLS

Для сайтов с поддержкой HTTPS оптимизация настроек SSL/TLS имеет решающее значение для снижения нагрузки на CPU и повышения производительности рукопожатия.

ssl_session_cache и ssl_session_timeout

Включите кэширование SSL-сессий, чтобы избежать вычислительно дорогостоящего полного TLS-рукопожатия для последующих соединений от того же клиента.

ssl_protocols и ssl_ciphers

Используйте современные, надежные протоколы TLS (такие как TLSv1.2 и TLSv1.3) и безопасные наборы шифров. Приоритизируйте серверные шифры с ssl_prefer_server_ciphers on.

ssl_stapling

Включает OCSP-сшивание, при котором Nginx периодически получает ответ OCSP от CA и «сшивает» его с рукопожатием SSL/TLS. Это уменьшает задержку на стороне клиента, избегая отдельного OCSP-запроса.

server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;

    ssl_session_cache shared:SSL:10m; # Общий кэш для 10 МБ данных сессии
    ssl_session_timeout 10m; # Сессии истекают через 10 минут

    ssl_protocols TLSv1.2 TLSv1.3; # Использовать современные, безопасные протоколы
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s; # Укажите DNS-резолверы для OCSP-запросов
    resolver_timeout 5s;
}

9. Кэш открытых файлов

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

open_file_cache

Включает кэш, указывая максимальное количество элементов и время, в течение которого неактивные элементы остаются.

open_file_cache_valid

Устанавливает, как часто кэш должен проверять валидность своих элементов.

open_file_cache_min_uses

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

open_file_cache_errors

Определяет, должен ли Nginx кэшировать ошибки при открытии файлов.

http {
    open_file_cache max=100000 inactive=60s; # Кэшировать до 100 000 файловых дескрипторов на 60 секунд
    open_file_cache_valid 80s; # Проверять валидность каждые 80 секунд
    open_file_cache_min_uses 1; # Кэшировать файлы, использованные хотя бы один раз
    open_file_cache_errors on; # Кэшировать ошибки, связанные с открытием файлов
}

Заключение

Настройка производительности Nginx — это непрерывный процесс, а не одноразовая установка. Этот контрольный список предоставляет надежную отправную точку для оптимизации ваших высоконагруженных веб-сайтов. Помните, что «идеальная» конфигурация сильно зависит от вашего конкретного приложения, паттернов трафика и ресурсов сервера. Всегда тестируйте изменения в тестовой среде перед развертыванием на продакшене и постоянно отслеживайте ваши экземпляры Nginx и бэкэнд-серверы с помощью таких инструментов, как мониторинг активности в реальном времени Nginx Plus, Prometheus, Grafana или базовые системные инструменты (например, top, iostat, netstat).

Тщательно применяя эти оптимизации и адаптируя их к вашей среде, вы можете гарантировать, что Nginx будет доставлять контент с исключительной скоростью, эффективностью и надежностью, даже при самых требовательных нагрузках.