Как оптимизировать nginx

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

Недурной исходной точкой для настройки nginx представляется конфиг, какой идёт в наборе с дистрибутивом, однако очень многие способности данного сервера в нём и не упоминаются. Очень сильно более детальный образчик имеется на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html. Хотя, давайте наилучше отведим скопить с нулевой отметки собственной конфиг, с бриджем и поэтессами.

Начнём с всеобщих опций. Для начала покажем юзера, от имени какого будет работать nginx от рута трудиться нехорошо, все ведают.

user nobody;

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

worker_processes 2;

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

error_log /spool/logs/nginx/nginx.error_log notice; # уровень уведомлений "notice", конечно, можно менять

Теперь же идёт весьма увлекательная секция «events». В ней возможно подать наибольшее число соединений, какие в одно время станет возделывать один процесс-воркер, и способ, какой будет применяться для извлечения асинхроичных уведомлений об событиях в ОС. Конечно, можно выкарабкать исключительно те способы, которые доступны на вашей ОС и были интегрированы при компиляции.

Данные характеристики смогут очутить порядочное воздействие на продуктивность вашего сервера. Их надобно выбирать персонально, исходя из ОС и железа. У меня есть возможность привести только немного всеобщих законов.

Модули работы с событиями:
— select и poll как обычно медленнее и достаточно сильно грузят процессор, но зато доступны абсолютно всюду, и трудятся практически постоянно;
— kqueue и epoll — больше результативны, однако доступны только в FreeBSD и Linux 2.6, сообразно;
— rtsig — довольно лучший метод, и удерживается и очень престарелыми линуксами, но сможет возбуждать проблемки при великом числе включений;
— /dev/poll — в какой мере ми общеизвестно, трудится в несколько более диковинных системах, типа соляриса, и в нём довольно результативен;

Метеопараметр worker_connections:
— Всеобщее максимальное количество обслуживаемых покупателей будет одинаково worker_processes * worker_connections;
— Временами могут износить в позитивную избежаю даже наиболее крайные смысла, вроде 128 действий, по 128 коннектов на процесс, либо 1 процесса, но с параметром worker_connections=16384. В заключительном случае, хотя, очень вероятно потребуется тюнить ОС.

events {
worker_connections 2048;
use kqueue; # У нас BSD
}

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


http {
# Весь код ниже будет внутри этой секции
# ...
}


Снутри данной секции смогут искаться немного достаточно увлекательных характеристик.

Целый призыв sendfile показался в Linux относительно на так давно. Он дает возможность послать исходные в сеть, избегая шаг их копирования в (целе)направленное место прибавления. В почти во всех вариантах сие значительно увеличивает продуктивность сервера, поэтому метеопараметр sendfile наилучше постоянно подключать.

sendfile on;

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

keepalive_timeout 15;

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

proxy_buffers 8 64k;
proxy_intercept_errors on;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Маленький трюк. В возникнувшем случае, если nginx обслуживает больше одного условного хоста, то есть смысл досоздать «условный хост по-умолчанию», какой станет возделывать требования тогда, когда сервер не может отыскать иной варианты по заголовку Host в запросе покупателя.

# default virtual host
server {
listen 80 default;
server_name localhost;
deny all;
}


Дальше сможет вытекать одна (либо немного) секций «server». В любой из их описывается условный хост (в первую очередь, name-based). Для собственников большого колличества страниц на одном хостинге, либо для хостеров тут может быть нечто, типа директивы

include /spool/users/nginx/*.conf;

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

server {
listen 80;

# Обратите внимание, в директиве server_name можно указать несколько имён одновременно.
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log timed;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Водворим шифровку для эффективности по-умолчанию.

charset utf-8;

И скажем, что мы не желаем получать от покупателей требования, протяженностью больше 1 мб.

client_max_body_size 1m;

Подключим для сервера SSI и просим для SSI-переменных оставить менее 1 кб.

ssi on;
ssi_value_length 1024;

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

set $www_root "/data/myserver/root";

location / {
proxy_pass 127.0.0.1:9999;
proxy_set_header X-Real-IP $remote_addr;
proxy_intercept_errors off;
proxy_read_timeout 5s; # Обратите внимание, здесь мы переопределили глобальную настройку, заданную выше
proxy_send_timeout 3s;
# ...


Раздельный блок в корневом локейшне приурочен к компрессии получаемого итога в gzip. Сие дозволит вам, и вашим юзерам поэкономить на трафике. Nginx возможно показать, какой-никакие типы файлов (либо, в данном случае, ответов от бэкенда) стоит стискивать, и какой-никаким обязан быть наименьший габарит файла затем, дабы употреблять стягивание.


# ...
gzip on;
gzip_min_length 1024;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/xml;
}

location /i/ {
root $www_root/static/;
}
}

Абсолютно всем благодарю за вниманье. И, сорри, что пост заполучился достаточно долгым.