Как оптимизировать конфигурацию Nginx
Введение
Nginx
Nginx — это быстрая и легкая альтернатива иногда властному Apache 2. Однако Nginx, как и любой сервер или программное обеспечение, необходимо настраивать для достижения оптимальной производительности.
Требования
- Свежий дроплет Debian 7 с завершенной первоначальной настройкой.
- В дроплете также должен быть только что установленный и настроенный сервер Nginx. Попробуйте руководство по блокам сервера Debian Nginx.
- Хорошее понимание основ Linux.
Рабочие процессы и рабочие соединения
Первые две переменные, которые нам нужно настроить, — это рабочие процессы и рабочие соединения. Прежде чем мы перейдем к каждой настройке, нам нужно понять, что контролирует каждая из этих директив. Директива worker_processes — это крепкий позвоночник Nginx. Эта директива отвечает за то, чтобы наш виртуальный сервер знал, сколько рабочих должно появиться после того, как он будет привязан к правильному IP-адресу и порту (ам). Обычной практикой является запуск одного рабочего процесса на ядро. Все, что выше этого, не повредит вашей системе, но оставит бездействующие процессы, которые обычно просто лежат.
Чтобы выяснить, какое число вам нужно установить для worker_processes, просто взгляните на количество ядер, которые у вас есть в вашей установке. Если вы используете установку DigitalOcean 512 МБ, то, вероятно, это будет одно ядро. Если вы в конечном итоге быстро измените размер до большей установки, вам нужно будет снова проверить свои ядра и соответствующим образом скорректировать это число. Мы можем сделать это, выбрав cpuinfo:
grep processor /proc/cpuinfo | wc -l
Допустим, это возвращает значение 1. Тогда это количество ядер на нашей машине!
Команда worker_connections сообщает нашим рабочим процессам, сколько людей может одновременно обслуживаться Nginx. Значение по умолчанию — 768; однако, учитывая, что каждый браузер обычно открывает как минимум 2 соединения на сервер, это число может быть вдвое меньше. Вот почему нам нужно настроить наши рабочие соединения на полную мощность. Мы можем проверить ограничения нашего ядра, введя команду ulimit:
ulimit -n
На меньшей машине (дроплет 512 МБ) это число, вероятно, будет выглядеть как 1024, что является хорошим начальным числом.
Обновим наш конфиг:
sudo nano /etc/nginx/nginx.conf
worker_processes 1;
worker_connections 1024;
Помните, что количество клиентов, которые могут быть обслужены, можно умножить на количество ядер. В этом случае мы можем обслуживать 1024 клиента в секунду. Однако директива keepalive_timeout еще больше смягчает это.
Буферы
Еще одна невероятно важная настройка, которую мы можем сделать, — это размер буфера. Если размеры буфера слишком малы, то Nginx придется писать во временный файл, что приведет к постоянному чтению и записи диска. Есть несколько директив, которые нам нужно понять, прежде чем принимать какие-либо решения.
client_body_buffer_size: обрабатывает размер клиентского буфера, то есть любые действия POST, отправляемые в Nginx. Действия POST обычно представляют собой отправку формы.
client_header_buffer_size: аналогична предыдущей директиве, только вместо этого она обрабатывает размер заголовка клиента. Для всех намерений и целей 1 КБ обычно является подходящим размером для этой директивы.
client_max_body_size: максимально допустимый размер клиентского запроса. Если максимальный размер превышен, Nginx выдает ошибку 413 или Request Entity Too Large.
large_client_header_buffers: максимальное количество и размер буферов для больших клиентских заголовков.
client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;
Тайм-ауты
Тайм-ауты также могут значительно повысить производительность.
Директивы client_body_timeout и client_header_timeout отвечают за время, в течение которого сервер будет ожидать отправки тела клиента или заголовка клиента после запроса. Если ни тело, ни заголовок не отправлены, сервер выдаст ошибку 408 или Время ожидания запроса истекло.
keepalive_timeout назначает тайм-аут для поддержания соединения с клиентом. Проще говоря, Nginx закроет соединения с клиентом по истечении этого периода времени.
Наконец, send_timeout устанавливается не на всю передачу ответа, а только между двумя операциями чтения; если по истечении этого времени клиент ничего не возьмет, то Nginx закрывает соединение.
client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;
Gzip-сжатие
Gzip может помочь уменьшить объем сетевой передачи, с которой имеет дело Nginx. Однако будьте осторожны, увеличивая gzip_comp_level слишком высоко, так как сервер начнет тратить такты процессора.
gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;
Кэширование статических файлов
Можно установить заголовки с истекающим сроком действия для файлов, которые не изменяются и обслуживаются регулярно. Эту директиву можно добавить в фактический блок сервера Nginx.
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
Добавляйте и удаляйте любые типы файлов в массиве выше, чтобы они соответствовали типам файлов ваших серверов Nginx.
Ведение журнала
Nginx регистрирует каждый запрос, поступающий на VPS, в файл журнала. Если вы используете аналитику для мониторинга, вы можете отключить эту функцию. Просто отредактируйте директиву access_log:
access_log off;
Сохраните и закройте файл, затем запустите:
sudo service nginx restart
Заключение
В конце концов, правильно настроенный сервер — это тот, который контролируется и соответствующим образом настраивается. Ни одна из перечисленных выше переменных не является фиксированной, и ее необходимо будет корректировать в каждом уникальном случае. В дальнейшем вы можете захотеть повысить производительность своей машины с помощью исследований в области балансировки нагрузки и горизонтального масштабирования. Это лишь некоторые из многих усовершенствований, которые хороший системный администратор может внести в сервер.