Компиляция nginx

./configure \
--prefix=%nginx_datadir \
--conf-path=%nginx_etc/nginx.conf \
--sbin-path=%{_sbindir}/%{name} \
--error-log-path=%nginx_log/nginx.error.log \
--http-log-path=%nginx_log/nginx.log \
--http-client-body-temp-path=%nginx_spool/tmp/client \
--http-proxy-temp-path=%nginx_spool/tmp/proxy \
--http-fastcgi-temp-path=%nginx_spool/tmp/fastcgi \
--pid-path=%_var/run/nginx.pid \
--user=%nginx_user \
--group=%nginx_group \
--with-cc-opt="-I %_includedir/pcre/" \
--with-http_ssl_module \
--with-http_realip_module \
--with-http_addition_module \
--with-http_sub_module \
--with-http_dav_module \
--with-http_flv_module \
--with-http_gzip_static_module \
--with-http_stub_status_module \
--with-http_perl_module

* This source code was highlighted with Source Code Highlighter.

Конфиг nginx - просто и понятно

user nginx;

# Число рабочих процессов, рекомендуется ставить по количеству ядер
worker_processes 8;

# Уменьшает число системных вызовов gettimeofday(), что приводит к увеличению производительности
timer_resolution 100ms;

# Изменяет ограничение на число используемых файлов RLIMIT_NOFILE для рабочего процесса.
worker_rlimit_nofile 8192;

# Директива задаёт приоритет рабочих процессов от -20 до 20 (отрицательное число означает более высокий приоритет).
worker_priority -5;

error_log /var/log/nginx/error.log;

pid /var/run/nginx.pid;

events {
worker_connections 2048;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;


log_format main '$remote_addr - $remote_user [$time_local] $request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

# Включить sendfile(). Использование sendfile() экономит системные вызовы, уменьшает число копирований данных,
№ позволяет использовать меньше физической памяти.
sendfile on;
keepalive_timeout 65;

gzip on;
gzip_min_length 1100;
gzip_buffers 64 8k;
gzip_comp_level 3;
gzip_http_version 1.1;
gzip_proxied any;
gzip_types text/plain application/xml application/x-javascript text/css;

# Load config files from the /etc/nginx/conf.vs directory
include /etc/nginx/conf.vs/*.conf;
}

* This source code was highlighted with Source Code Highlighter.

server {
listen 80;
server_name _;

location / {
gzip_static on;
root /var/nginx/html;
index index.html index.htm;
}

error_page 404 /404.html;
location = /404.html {
root /var/nginx/html;
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/nginx/html;
}
}

* This source code was highlighted with Source Code Highlighter.

Мониторинг сервера nginx

  location = /stat {
    stub_status on;
    access_log  off;
    allow xx.xx.xx.xx;
    deny all;
  }

* This source code was highlighted with Source Code Highlighter.

LoadModule rpaf_module modules/mod_rpaf-2.0.so

#
# Mod rpaf
#

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 xx.xx.xx.xx
RPAFheader X-Forwarded-For

* This source code was highlighted with Source Code Highlighter.

ExtendedStatus On
<Location /apache-stat>
SetHandler server-status
Deny from all
Allow from xx.xx.xx.xx
</Location>

* This source code was highlighted with Source Code Highlighter.

Типы статического контента

"Легкий" контент: html, css, js, xml, rss, txt. Он хорошо поддается сжатию, требует мало места для хранения. Приминение nginx в любом случае даст заметный прирост производительности.

"Тяжелый" контент: фото, видео, аудио-файлы. Узким местом выступает, в первую очередь дисковая система, размер оперативной памяти, пропускная способность канала. Задача раздачи такого типа контента делится на 2 - хранение контента и, собственно, раздача контента. С помощью nginx можно добиться минимального расхода памяти и процессорного времени, но при увеличении нагрузки все же прийдется собирать RAID-масив.

Что делать когда сайт начинает тормозить

1. Попробуйте увеличить количество worker_processes, автор nginx советует устанавливать их по количеству ядер. Я варьировал это количество приблизительно в диапазоне "количеству ядер" - "количеству ядер x 2", при этом добивался более быстрого установление соедиенения, но не всегда более оперативной обработки http-запроса. Не забудьте, что есть еще worker_connections (максимальное количество конекшинов для одного worker)
2. Поможет установка worker_priority в -5 и меньше (до -20). Тут будьте осторожны, так как другие сервисы могут начать заметно тормозить. На наших серверах этот параметрт установлен в -5. Чем меньше значение - тем выше приоритет для nginx
3. При большом количестве отдачи мелких файлов и медленном винчестере может помочь временное отключение логов access_log off.
4. Ищите узкое место, может его можно устранить. Вам помогут комманды: top, iostat, df -h, iptraf
5. Добавьте оперативной памяти или усовершенствуйте дисковую систему (например установите RAID-масив, можно поэкспериментировать с SSD-винчестером)

Приемы оптимизации

"Легкий" контент

1. Виртуальный диск.
   Создаем виртуальный диск (tmpfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент) переносим туда и в конфиге nginx, отдельно прописываем

   location /js/ {
   root /var/www/img_virtual/auto.ria.ua/js
   }
   ...
   

   Для того, чтоб виртуальный диск создавался автоматически при перезагрузке в /etc/fstab добавляем

   none /var/www/img_virtual tmpfs size=1g,mode=1777 0 0

   (при старте системы автоматически будет создаваться диск, размером 1G)
2. Сжатие контента gzip-ом
   Запускаем в нашей виртуальной папке

   for i in `find ./* -type f -name '*.js'`; do echo $i; gzip -c -9 $i > $i.gz; done;
   for i in `find ./* -type f -name '*.css'`; do echo $i; gzip -c -9 $i > $i.gz; done;
   

   в конфиг nginx добавляем строчку gzip_static on :

   location /js/ {
   gzip_static on;
   root /var/www/img_virtual/auto.ria.ua/js
   }
   

   Также можно включить online упаковку для динамических файлов:

   location / {
   gzip on;
   gzip_min_length 1100;
   gzip_buffers 16 8k;
   gzip_comp_level 3;
   gzip_types text/plain application/xml application/x-javascript text/css;
   
   root /var/www/auto.ria.ua/
   }
   

3. Заголовки для проксирования контента
   Указание в заголовках времени жизни статического контента также приведет к уменьшению нагрузки. Для этого будем использовать директиву expires. Если контент не будет меняться, со вренем можно использовать expires max. Даже expires 1d даст хороший результат
4. Кеширование дескрипторов файлов
   Это даст прирост производительности, если у вас множество мелких файлов с развернутой иерархией директорий. Также можно закешировать обращение к несуществующим файлам. Выглядеть это будет приблизительно так:

   location / {
   root /var/www/;
   
   
   open_file_cache max=1024 inactive=600s;
   open_file_cache_valid 2000s;
   open_file_cache_min_uses 1;
   open_file_cache_errors on;
   }
   

"Тяжелый" контент

1. Вначале надо обратить внимание на то, не используется ли swap при отдаче контента, если да то это может быть проблемой, если swap находится на обычном SATA-винчестере. Свопиться любит metod ядра "sendfile", это безусловно прогрессивная технология, но использование swap будет существенно влиять на отдачу и тогда я советую его отключить директивой sendfile off;
2. Если позволяет оперативная память, создайте виртуальный диск, на который поместите самые "запрашиваемые" файлы, со временем, скажем, раз в 10 минут вы можете корректировать список этих файлов. Теперь мы можем применить директиву try_files:

   location / {
   root /var/www/;
   try_files /img_virtual/hot/$uri @storage;
   }
   
   location @storage {
   proxy_pass http://backend;
   proxy_set_header Host $host;
   }
   

   Если файл не будет найден, на виртуальном диске будет обращение к backend.
   
   Как правило "гарячий контент" составляет менее 10% от общего объема.
   
   Если свою программу по формированию кеша писать нет возможности, используйте директиву proxy_store

   location @storage {
   proxy_pass http://backend;
   proxy_set_header Host $host;
   
   proxy_store on;
   proxy_store_access user:rw group:rw all:r;
   proxy_temp_path /var/www/img_virtual/hot/;
   root /var/www/img_virtual/hot/;
   }
   

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

   cd /var/www/img_virtual/hot/
   find ./ -type f -amin +60 -delete
   

   (если файл из кеша не запрашимвается более 60 минут, мы его удаляем)
3. Если storage большой, занимает терабайты -- оперативой вопрос не решить. Можно на фронтенд-е собрать RAID. Не советую использовать fake-raid, это головная боль при апгрейде и при пропадании света! Берем побольше винтов SAS, берем полноценный RAID-котроллер (никаких hostraid!). Монтируем туда swap, spool и кеш. Для нечасто меняющегося контента и нечастой перезаписи кеша можно применять SSD-винчестеры. Это работает быстро, у таких винчестеров нет такой характеристики как seek-to-seek, малый расход энергии (например для Intel X25-M 0,15Вт), хорошая скорость отдачи (до 250 MB/s).
4. Кеширование проксированых запросов.
   23 марта 2009 года вышла очередная бета nginx 0.7.44, в которой появилась экспериментальная поддержка кеширования проксированных запросов. Трудно переоценить важность этого события для пользователей nginx. Автор nginx вручает нам мощный инструмент в управлении раздачи большого объема статики.
   Почему нужен такой кеш? Ответ на этот вопрос главным образом связан с разной "стоимостью" дисковой операции и сетевой операции. "Сходить" на диск во многих случаях значительно "дешевле", чем обращение в сеть. Главная задача такого кеширования сводится к сведению к необходимому минимуму сетевых опрераций и "интелектуальному управлению" дисковым кешем.
   Подробнее о настройки кеша проксированных запросов.