• База знаний
  • /
  • Блог
  • /
  • Wiki
  • /
+380 (44) 364 05 71

После того как Вы узнали как правильно настроить ядро 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-соединений своими закачками;
  • не хотим, чтобы нам исчерпали вычислительные ресурсы БД множеством поисковых запросов.

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

Установка лимитов limit_conn и limit_req

На расчет данных лимитов мы выделили словарь с буфером в 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 сервисов:

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

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

Дата: 13.09.2019
Автор: Валерий

Авторам статьи важно Ваше мнение. Будем рады его обсудить с Вами:

comments powered by Disqus
Спасибо, что выбираете FREEhost.UA