Nginx - это бесплатный высокопроизводительный и легкий веб-сервер с открытым исходным кодом, который используется в качестве балансировщика нагрузки, обратного прокси, HTTP-кэша и почтового прокси. Хотя Nginx довольно новый по сравнению с другими веб-серверами, его популярность растет благодаря высокой производительности. При стандартной конфигурации Nginx вы можете получить высокую производительность, но мы можем увеличить производительность Nginx до максимума, изменив некоторые настройки.
Изменение рабочих процессов
Все запросы веб-сервера в Nginx обрабатываются рабочим процессом. В Nginx рабочие процессы организованы в виде нескольких рабочих процессов для обработки запроса, а один главный процесс отвечает за управление всеми рабочими процессами, а также за анализ конфигурации. В конфигурации Nginx по умолчанию параметр рабочего процесса установлен на auto, что порождает рабочий процесс в зависимости от доступного ядра процессора. Как рекомендует официальная документация Nginx, это лучший способ поддерживать рабочий процесс в соответствии с доступным ядром процессора, поэтому auto является рекомендуемым параметром. Если вам интересно узнать, сколько ядер у вашего процессора, просто выполните следующую команду.
| 1 | grep processor /proc/cpuinfo | wc -l |
Вы можете изменить значение рабочего процесса по умолчанию в конфигурационном файле Nginx, который находится по адресу /etc/nginx/nginx.conf. Если ваш сервер испытывает повышенный трафик и вам необходимо добавить больше рабочих процессов, лучше обновить сервер до более мощных процессоров.
| 1 | worker_processes 8; |
Повышение лимита соединений воркеров
Рабочее соединение - это общее количество одновременных соединений, которыми может управлять каждый доступный рабочий процесс. По умолчанию рабочий процесс может управлять 512 соединениями одновременно. Перед изменением значения рабочего соединения необходимо проверить максимальное количество соединений, которое может разрешить система, используя следующую команду, чтобы обновить конфигурацию соединения в соответствии с ней.
| 1 | ulimit -n |
Чтобы увеличить потенциал Nginx, установите в файле nginx.conf значение рабочего соединения на максимальное значение, разрешенное системой.
| 1 2 3 | events { worker_connections 1024; } |
Внедрение сжатия контента
Для сжатия веб-контента Nginx использует gzip, чтобы увеличить время доставки контента и уменьшить использование пропускной способности сети. В конфигурации вы можете найти конфигурацию gzip в закомментированном состоянии, но вы можете разкомментировать и изменить gzip в соответствии с вашими потребностями. Поскольку процесс сжатия gzip использует системные ресурсы, если у вас ограниченные ресурсы, измените конфигурацию в соответствии с этим, например, сжимайте только определенный тип файлов, уровень сжатия и т.д.
Кэширование статического содержимого
В современном веб-разработке большинство содержимого статически передается браузеру или клиенту, поэтому кэширование статических файлов ускоряет загрузку содержимого. Это также уменьшит количество запросов на подключение к Nginx, поскольку содержимое загружается из кэша. Чтобы запустить процесс кэширования, добавьте следующую директиву в файл конфигурации виртуального хоста Nginx.
| 1 | location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {expires 30d;} |
Приведенная выше директива кэширует файл ресурса на 30 дней. Вы можете установить срок действия кэша в соответствии с вашими потребностями.
Буферизация
Буферизация может сделать взаимодействие между клиентом и сервером более эффективным, поскольку она удерживает часть ответа до заполнения буфера. Если ответ слишком велик по сравнению с фактическим размером буфера, Nginx будет записывать его на диск, что может привести к снижению производительности. Вы можете изменить следующую директиву, чтобы отрегулировать размер буфера в соответствии с вашими требованиями.
Client_body_buffer_size: Определяет фактический размер буфера, который используется для хранения данных ответа клиента.
Client_header_buffer_size: Управляет размером клиентского заголовка. Обычно достаточно установить значение 1k.
Client_max_body_size: Ограничивает максимальный размер тела ответа, разрешенный клиенту. Если размер тела превышает его значение, Nginx выдаст ошибку "Request Entity Too Large".
Чтобы настроить размер буферизации, добавьте следующую директиву в раздел http.
| 1 2 3 4 5 6 7 | http { … client_body_buffer_size 80k; client_max_body_size 9m; client_header_buffer_size 1k; ... } |
Буферизация журнала доступа
Ведение журнала - одна из важнейших ролей в отладке проблемы и аудите. Так как в журнале хранятся данные каждого запроса, что влияет на циклы ввода-вывода и процессор, что приводит к проблемам с производительностью. Вы можете уменьшить это влияние, включив буферизацию журнала. Как только размер буфера достигает своего предела, Nginx записывает содержимое буфера в журнал. Вы можете включить буферизацию, добавив параметры буфера со значениями размера в директиву access log.
| 1 | access_log /var/log/nginx/access.log main buffer=16k; |
Или вы можете отключить журнал доступа (если он не нужен) следующим образом.
| 1 | access_log off; |
Ограничение значения тайм-аута
Ограничение значения тайм-аута повышает производительность Nginx. Nginx будет ожидать тело и заголовок запроса клиента в течение заданного периода времени. Если данные ответа не будут получены вовремя, Nginx устанавливает тайм-аут для соответствующего клиента. Значением тайм-аута можно управлять с помощью следующей директивы. Чтобы задать длительность тайм-аута, скопируйте приведенную ниже директиву в раздел http.
| 1 2 3 4 | client_body_timeout 10; client_header_timeout 10; keepalive_timeout 13; send_timeout 10; |
client_body_timeout и client_header_timeout - это период времени, в течение которого Nginx должен прочитать заголовок и тело запроса клиента. Если запрос не будет завершен вовремя, он будет прерван с ошибкой time out.
Keepalive_timeout - это время, в течение которого после закрытия nginx клиентского соединения keep-alive соединение остается открытым.
Send_timeout - это время, в течение которого клиент должен получить ответ, отправленный Nginx.
Открытый файловый кэш
В Linux почти все является файлом, при использовании open_file_cache дескриптор файла и все часто используемые файлы кэшируются на сервере. Особенно при обслуживании статических Html файлов использование кэша открытых файлов увеличит производительность Nginx, так как он открывает и хранит кэш в памяти в течение заданного интервала времени. Поместите следующую директиву open_file_cache в секцию http, чтобы инициировать кэширование.
| 1 2 3 4 5 6 | http { ... open_file_cache max=1024 inactive=10s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on; |