Тонкая настройки NGINX

После того как Вы узнали как правильно настроить ядро Linux и использовать файрвол самое время перейти к оптимизации работы вебсервера NGINX.

Лимитируем размеры буферов в nginx

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

• client_header_buffer_size Задает размер буфера для чтения заголовка запроса клиента. Если запрос не помещается в этот буфер, то выделяются буферы большего размера, задаваемые директивой large_client_header_buffers.
• large_client_header_buffers Задает максимальное число и размер буферов для чтения большого заголовка запроса клиента.
• client_body_buffer_size Задает размер буфера для чтения тела запроса клиента. Если тело запроса больше заданного буфера, то все тело запроса или только его часть записывается во временный файл.
• client_max_body_size Задает максимально допустимый размер тела запроса клиента, указываемый в поле «Content-Length» заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).

Настраиваем таймауты в nginx

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

• reset_timedout_connection on; Разрешаем сброс соединений по таймауту . Помогает бороться с сокетами, зависшими в фазе FIN-WAIT.
• client_header_timeout Задает тайм-аут при чтении заголовка запроса клиента. За это время клиенту необходимо передать полностью заголовок , в противном случае обработка запроса прекратится.
• client_body_timeout Задает тайм-аут при чтении тела запроса клиента.
• keepalive_timeout Задает тайм-аут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера.
• send_timeout Задает тайм-аут при передаче ответа клиенту. Соединение будет закрыто, если по истечении этого времени клиент ничего не примет,

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

Как найти значения размера буфера или таймаута nginx?

1. Выставляем минимальное значение параметра.
2. Запускаем прогон тестов сайта.
3. Если весь функционал сайта работает без проблем — параметр определен. Если нет — увеличиваем значение параметра и переходим к пункту. 2.
4. Если значение параметра превысило даже значение по умолчанию — это повод для обсуждения в команде разработчиков.

Лимитируем соединия в nginx limit_conn и limit_req

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

Предположим, что на сайте есть разделы download и /search. При этом мы:

• не хотим, чтобы нам забили таблицу TCP-соединений своими закачками;
• не хотим, чтобы нам исчерпали вычислительные ресурсы БД множеством поисковых запросов.

Для этих целей можно применить следующую конфигурацию:

На расчет данных лимитов мы выделили словарь с буфером в 10 мегабайт , и в качестве ключа используется IP-адрес клиента , так же для зоны search мы ограничили скорость обработки запросов до 1 запроса в секунду.

Так же имеет смысл добавить ограничения limit_req и limit_conn для locations, в которых находятся тяжелые к выполнению скрипты. Ограничения необходимо подбирать, руководствуясь результатами нагрузочного, а также здравым смыслом.

Общие директивы оптимизации nginx:

worker_processes 12; Его количество должно быть равным количеству ядер процессора в вашей системе.

worker_connections 4000; Определяет какое кол-во клиентов будет обслуживаться одним worker_process

worker_rlimit_nofile 100000; Директива изменяет ограничение на кол-во открытых файлов. Для каждого соединения нужно добавить по два дексриптора : один для соединения , а второй — для открытия файла.

multi_accept on; Директива указывает nginx принимать максимальное кол-во подключений.

Включаем кеширование и сжатие:

open_file_cache max=100000 inactive=20s;

open_file_cache_valid 30s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

gzip on;

gzip_comp_level 5;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

gzip_disable "msie6";

Чем проверить скорость загрузки сайта и допустимую нагрузку?

После изменения настроек NGINX скорость загрузки сайта можно проверить при помощи следующих online сервисов:

• Google Pageseed Insigts
• Pingdom Tools
• SiteSpeed.me

Для консольного тестирования хорошо подходит утилита ApacheBench.

Наш дата-центр предлагает полный спектр услуг хостинга. У нас Вы можете купить linux vps или арендовать выделенный сервер. Автоматически на сервер будет установлена операционная система Linux по Вашему выбору, а так же дополнительное программное обеспечение: mysql, php, apache, nginx, exim.