Yvision.kzYvision.kz
kk
Разное
Разное
399 772 постов41 подписчиков
Всяко-разно
0
22:02, 12 мая 2011

Настройка nginx

Nginx - отличный и высокопроизводительный Web сервер. В стандартной конфигурации он может работать при достаточно больших нагрузках. Тем не менее, эффективность его работы можно повысить, подкорректировав некоторые настройки.

Ищите файл nginx.conf на своем сервере и открывайте его…

sudo nano /etc/nginx/nginx.conf

Stub Status

В nginx есть модуль “StubStatus”, который показывает несколько параметров текущего состояния. Показателей мало, но они полезные, и без них никуда. Работает этот модуль по HTTP, следовательно для него стоит создать либо отдельный хост, либо написать правило для директивы location. Поднимем дополнительный хост, причем на нестандартном порту:

server
{
listen *:8899;
server_name stub.example.com;

location /
{
stub_status on;
access_log off;
# Если хотите дать доступ только своему IP адресу, добавьте эти строки:
# allow 111.222.333.444;
# deny all;
}
}

После этого, зайдя в браузере по адресу “http://stub.example.com:8899″, увидим такую скромную страницу (естесвенно, с другими числами):

Active connections: 369
server accepts handled requests
96296 96296 170563
Reading: 16 Writing: 133 Waiting: 220

Обновите несколько раз страницу, числа отображаются в реальном времени. Что все это значит:

  • Active connections - количество открытых соединений
  • server accepts handled requests - Сервер принял 96296 соединения, обработал 96296 соединения и обработал 170563 запроса (1.77 запросов/соединение)
  • Reading - количество запросов, заголовки которых nginx читает в данный момент
  • Writing - количество запросов, тело которых читает nginx + количество запросов для которых nginx отдает данные
  • Waiting - количетсво keep-alive соединений, расчитывается как: waiting = active - reading - writing

Проследите за тем, что-бы показания accepts и handled совпадали (иначе Ваш nginx обрывает соединения по причине нехватки свободных потоков)

Количество соединений

Количество клиентов, которых может обслуживать nginx, настраивается следующими параметрами.

worker_processes 8;
events {
use epoll;
worker_connections 1024;
}

В случае, если nginx используется, как Web сервер (не как реверсный прокси), количество активных клиентов = worker_processes*worker_connections

Директива use устанавливает метод обработки соединений. Nginx поддерживает следующие методы:

  • select — стандартный метод. Модуль для поддержки этого метода собирается автоматически, если на платформе не обнаружено более эффективного метода
  • poll — стандартный метод. Модуль для поддержки этого метода собирается автоматически, если на платформе не обнаружено более эффективного метода
  • kqueue — эффективный метод, используемый во FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и MacOS X
  • epoll — эффективный метод, используемый в Linux 2.6+
  • rtsig — real time signals, эффективный метод, используемый в Linux 2.2.19+. По умолчанию в очереди может находиться не более 1024 сигналов для всей системы. Этого недостаточно для нагруженных серверов, поэтому нужно увеличить размер очереди с помощью параметра ядра /proc/sys/kernel/rtsig-max. Однако, начиная с Linux 2.6.6-mm2, этого параметра уже нет и для каждого процесса существует отдельная очередь сигналов, размер которой задаётся с помощью RLIMIT_SIGPENDING

Увеличение worker_processes позволит добиться более эффективной работы, если у Вас много одновременных соединений и есть затычки в дисковой системе. Каждый отдельный поток работает независимо от остальных, соответственно не будет промедлений. Но учтите, каждый поток отнимает больше ресурсов (и процессора и памяти).
worker_connections - количество соединений на каждый отдельный воркер (поток) - стоит ставить в пределах 500…2000.

Прокси буферы

Если Вы пользуетесь модулем прокси в nginx, то Вам стоит учесть следующее. Для начала, типичная настройка для проксирования php бекендов:

server {
listen 80;
server_name example.org;

location / {
proxy_next_upstream error;
proxy_set_header Host $host;
proxy_pass http://backend;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

В проксировании очень важны настройки буферизации ответов от бекенд серверов:

  • proxy_buffers чилсо размер - Директива задаёт число и размер буферов для одного соединения, в которые будет читаться ответ, получаемый от проксируемого сервера
  • proxy_buffering on|off - Директива разрешает использовать буферизацию ответа проксируемого сервера. Если буферизация включена, то nginx принимает ответ проксируемого сервера как можно быстрее, сохраняя его в буфера, заданные директивами proxy_buffer_size и proxy_buffers. Если ответ не помещается полностью в память, то его часть записывается на диск! Если буферизация выключена, то ответ синхронно передаётся клиенту сразу же по мере его поступления. nginx не пытается считать весь ответ проксируемого сервера, максимальный размер данных, который nginx может принять от сервера задаётся директивой proxy_buffer_size
  • proxy_buffer_size размер - Директива задаёт размер буфера, в который будет читаться первая часть ответа, получаемого от проксируемого сервера. В этой части ответа находится, как правило, небольшой заголовок ответа. По умолчанию размер буфера равен размеру одного буфера в директиве proxy_buffers, однако его можно сделать меньше

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

Сжатие

Все современные браузеры поддерживают прием контента в сжатом виде (gzip). Включение сжатия рекомендуется для статики и text/plain, html, xml, rss файлов. Это поможет экономть канал + повысить скорость загрузки страниц на клиентах:

gzip on;
gzip_buffers 4 8k;
gzip_comp_level 7;
gzip_proxied any;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

В завершение, несколько полезных линков:
StubStatus модуль
Events модуль
Gzip модуль

Источник: Highload

0
882
0