Nginx? Назначение, особенности, варианты настроек - это вещи, с которыми должен быть ознакомлен каждый веб-разработчик, чтобы тестировать свои наработки.
О nginx замолвим слово
Данный инструмент обладает одним главным и несколькими рабочими процессами. Первый занимается чтением и проверкой конфигурации. Также под его контролем находится управление рабочими процессами. Задача последних - обрабатывать поступающие запросы. В nginx применяется модель, что базируется на событиях. Также используются механизмы, зависимые от операционной системы, чтобы добиться эффективного распределения запросов непосредственно между рабочими процессами. Их количество всегда обозначено в конфигурационном файле. Значение может быть как фиксированным, так и устанавливаться автоматически, ориентируясь по числу процессорных ядер, с которыми можно работать. В nginx настройка системы и модулей проводится с помощью конфигурационного файла. Поэтому, если надо что-то изменить, то искать необходимо именно его. Обычно он находится в директиве /etc/nginx (но путь может меняться при использовании других систем) и имеет расширение.conf.
Запуск, перезагрузка и логи
Для этого необходимо заставить работать исполняемый файл. Настройка nginx-сервера возможна, только когда он запущен. Управление осуществляется благодаря вызову исполняемого файла с параметром -s. Для этого используйте такую запись:
nginx -s сигнал
В данном случае подставлять можно такие команды (должны поступать от пользователя, что запустил инструмент):
- Stop. Используется для быстрого завершения работы.
- Reload. Команда необходима, чтобы перезагрузить конфигурационный файл. Дело в том, что любые изменения не будут применены, пока файл работает. И чтобы они вступили в силу, необходима перезагрузка. Как только будет получен этот сигнал, главный процесс начнёт проверять правильность синтаксической составляющей конфигурационного файла и попробует применить имеющиеся там указания. В случае неудачи он откатит изменения и будет работать со старыми параметрами. Если всё произошло успешно, то будут запущены новые рабочие процессы, а старым будет отправлено требование завершиться.
- Quit. Применяется для плавного завершения работы. Применяется, если необходимо подождать, пока закончат обслуживаться текущие запросы.
- Reopen. Закрыть и открыть лог-файлы.
Использование утилит
Настройка процессов может осуществляться также с помощью средств Unix (в качестве примера будет рассмотрена утилита kill). Обычно они используют механизм отправки процессу сигнала напрямую с данными. Увязываются они с помощью ID. Эти данные хранятся в файле nginx.pid. Допустим, что нас интересует процесс №134. Тогда для плавного завершения нам необходимо отправить следующую информацию:
kill -s QUIT 1628
Допустим, что мы хотим просмотреть список всех запущенных файлов. Используем для этого утилиту ps. Команда же будет выглядеть следующим образом:
ps -ax | grep nginx
То есть, как видите, при использовании дополнительного инструментария указывается, что идёт именно его применение. А теперь давайте сконцентрируемся на том, как совершается nginx-настройка.
Структура конфигурационного файла
Установка и настройка nginx предусматривает работу с модулями. Они настраиваются с помощью директив, которые указываются в конфигурационном файле. Они бывают простыми и блочными. Первый тип директив состоит из имени и параметров, которые разделяются с помощью пробелов, а их конец указывается точкой с запятой - (;). Блочная имеет похожее строение. Но в данной директиве вместо окончания размещается набор дополнительных инструкций, которые размещают в фигурных скобах ({ указания }). Если в них можно разместить имена и параметры других процессов, то называются такие конструкции уже контекстом. В качестве примера можно привести http, location и server.
Раздача статического содержимого
Это одна их самых важных задач, которая стоит перед конфигурацией nginx. Под раздачей статистического содержимого подразумевают изображения и HTML-страницы (не динамические). Допустим, что нам нужна разовая работа по настройке nix nginx кластера. Сложно ли это сделать? Нет, и давайте рассмотрим пример. Прежде чем приступать к нему, необходимо детализировать условия задачи. Так, зависимо от запросов, файлы будут идти из разных локальных каталогов. Так, в /data/www мы имеем HTML-документы. А в каталоге /data/images содержатся изображения. Оптимальная настройка nginx в данном случае требует редактирования конфигурационного файла, в котором необходимо настроить блок server внутри http. Для поддержки будет использоваться также два location.
Реализация: server
Итак, для начала нам необходимо создать сами каталоги и разместить в них файлы с необходимыми расширениями (в html необходимо добавить содержимое). Затем открываем конфигурационный файл. В нём по умолчанию уже есть несколько блоков server, которые в массе своей закомментированы. Чтобы добиться оптимального результата, этот процесс необходимо проделать по отношению ко всем составляющим по умолчанию. Затем добавляем новый блок server с помощью такого кода:
Конфигурационный файл может работать с несколькими такими блоками. Но они должны отличаться своими именами и портами, с помощью которых происходит получение данных.
Реализация: location
Определяется внутри server:
Наличие знака «/» необходимо, чтобы сравнивать получаемые данные и смотреть, есть ли такой адрес из обработанного запроса здесь. Если никаких проблем нет, то указываем путь /data/www к необходимому файлу, что находится в данной локальной системе. Если совпадение есть с несколькими блоками, то выбирается тот, у которого самый длинный префикс. В приведённом примере его длина равняется единице, то есть использование будет исключительно в том случае, если нет «конкурентов». Теперь давайте его усовершенствуем:
location /images/ {
Как можете определить, ищем мы изображения. А теперь давайте совместим все наработки, которые были ранее, и конфигурация на данный момент выглядит следующим образом:
location /images/ {
Это рабочий вариант, который случает стандартный Этот сервер без проблем может быть доступный на локальном компьютере, если пройти по адресу: http://localhost/. Как же это всё будет работать?
Принцип функционирования примера
Итак, когда придут запросы, что начинаются с с /images, то сервером файлы из соответствующего каталога будут отправляться пользователю. При его отсутствии будет передана информация, указывающая на ошибку 404. Если проводится настройка nginx на локальном компьютере, то при запросе http://localhost/images/example.png нами будет получен файл, месторасположение которого /data/images/example.png. При указании одного символа «/» поиск будет проводиться в директории /data/www. Но мы только изменили конфигурацию. Чтобы она начала работать, её необходимо перезагрузить. Для этого используйте команду nginx -s reload. В случае когда нормальная работа не является возможной, то в файлах error.log и access.log, расположенных в директиве /usr/local/nginx/logs, вы сможете поискать причину неисправностей.
Создание простого прокси-сервера
Можно сказать относительно nginx - настройка данного объекта является одним из частых применений (и довольно легким, между прочим). Здесь используется принцип сервера, который принимает запрос, а потом осуществляет перенаправление их к необходимым сайтам. После этого ожидается ответ от них, который направляет их к тому, кто поставил задачу. Поэтому давайте рассмотрим пример создания базовой точки. Она будет заниматься обслуживанием запросов пользователей и предоставлять им изображения из локального каталога. Итак, к блоку http добавляем ещё один server с таким содержимым:
А теперь давайте для вас расшифрую: создаётся простой сервер. Он будет прослушивать Не указать listen, то сервер будет работать на 80-м. Отображаться будут все запросы в рамках локальной файловой системы, которые направлены на каталог /data/up1 (конечно, его перед этим необходимо будет создать). Для возможности проверки там необходимо поместить файл index.html. Благодаря размещению директивы root в контексте server мы сможем воспользоваться location при любых условиях (поскольку, таким образом, снимаются ограничения доступа). Теперь работаем над созданием прокси-сервера. Для его работы нам понадобится директива proxy_pass, для которой будут указаны протокол, имя, а также порт объекта как параметры (при локальном подключении это будет выглядеть как http://localhost:8080). Получится такой результат:
proxy_pass http://localhost:8080;
location /images/ {
Если вы рассматриваете код и анализируете его, то можете заметить, что второй блок location был изменён. Так, в данном случае он может работать с типичными расширениями изображений. Немного по-другому его можно было бы отобразить таким образом:
location ~ \.(gif|jpg|png)$ {
root /data/images;
Итоговая конфигурация прокси-сервера выглядит следующим образом:
proxy_pass http://localhost:8080/;
location ~ \.(gif|jpg|png)$ {
root /data/images;
Он будет отфильтровывать запросы, в конце которых имеются указанные расширения, и отправлять их тому, кто попросил файлы. Не забывайте, что при желании проверить файл конфигурации его необходимо будет перезагрузить. И поверьте, это простейшая nginx-настройка. Если открыть конфигурационный файл сервера «Вконтакте» или другой крупной компании, у них будет кода больше, чем слов в этой статье.
Веб-сервер Nginx - это один из самых популярных веб-серверов с очень высокой производительностью и быстрой обработкой статических запросов от пользователей. При правильной настройке можно добиться очень высокой производительности от этого веб-сервера. Nginx очень быстро справляется со статическими файлами, будь то html страницы или другие виды ресурсов.
В одной из предыдущих статей мы уже рассматривали и настройку его основных параметров, в этой же статье я хочу больше остановиться на производительности и подготовке веб-сервера к использованию в боевых условиях. Что касается дистрибутива Linux, то сегодня мы будем рассматривать CentOS, эта система часто используется на серверах и с настройкой Nginx тут могут возникнуть некоторые сложности. Дальше будет рассмотрена настройка Nginx CentOS, поговорим как включить полную поддержку http2, google pagespeed, и настроить основной конфигурационный файл.
В официальных репозиториях CentOS есть Nginx и он, скорее всего, уже установлен в вашей системе. Но мы хотим чтобы сайт работал по протоколу http2, который позволяет передавать все данные одним подключением, а это увеличивает производительность. Для работы по http2 вам понадобиться настроить SSL сертификат, но об этом уже написано в статье получение сертификата Lets Encrypt Nginx. Но это еще не все. для переключения с обычного SSL на HTTP2.0 в большинстве браузеров сейчас используется протокол ALPN, а он поддерживается начиная с OpenSSL 1.02. В то время, как в репозиториях есть только OpenSSL 1.01. Поэтому нам нужно установить версию Nginx, собранную с OpenSSL 1.02. Для этого можно использовать Broken Repo:
sudo yum -y install yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo
Если вы используете репозиторий EPEL, то нужно указать что не надо из него брать Nginx:
sudo yum-config-manager --save --setopt=epel.exclude=nginx*;
Теперь для установки правильной версии Nginx достаточно набрать:
sudo yum install nginx
Будет установлена самая последняя версия Nginx 1.13.2, с полной поддержкой ALPN. Дальше перейдем к настройке.
2. Настройка Nginx
Первым делом следует рассмотреть структуру конфигурационного файла. На первый взгляд, тут все может показаться очень запутанным, но там все достаточно логично:
глобальные опции
events {}
http{
server {
location{}
}
server {}
}
Сначала идут глобальные опции, которые задают основные параметры программы, например, от какого пользователя она будет запущена и количество процессов. Дальше есть секция events , в которой описано как Nginx будет реагировать на входящие подключения, затем идет секция http , которая объединяет все настройки касаемо работы протокола http. В ней находится секция server , каждая такая секция отвечает за отдельный домен, в секции server размещаются секции location , каждая из которых отвечает за определенный URL запроса, обратите внимание, что не файл на сервере, как в Apache, а именно URL запроса.
Основные глобальные настройки мы будем делать в файле /etc/nginx/nginx.conf. Дальше рассмотрим что именно будем менять и какие значения желательно установить. Начнем с глобальных опций:
- user - пользователь, от имени которого будет запущен сервер, должен быть владельцем каталога с файлами сайта, и от имени его же нужно запускать php-fpm;
- worker_processes - количество процессов Nginx, которые будут запущены, нужно установить ровно столько, сколько у вас есть ядер, например, у меня - 4;
- worker_cpu_affinity - этот параметр позволяет закрепить каждый процесс за отдельным ядром процессора, установите значение auto, чтобы программа сама выбрала что и к чему крепить;
- worker_rlimit_nofile - максимальное количество файлов, которые может открыть программа, на каждое соединение нужно как минимум два файла и каждый процесс будет иметь указанное вами количество соединений, поэтому формула такая: worker_processes * worker_connections* 2, параметр worker_connections разберем чуть ниже;
- pcre_jit - включите этот параметр для ускорения обработки регулярных выражений с помощью JIT компиляции;
В секции events стоит настроить два параметра:
- worker_connections - количество соединений для одного процесса, должно быть достаточным для обработки входящих соединений. Сначала нам нужно знать сколько этих входящих соединений есть, для этого смотрим статистику по адресу ip_сервера/nginx_status. Как включить рассмотрим ниже. В строке Active Connections видим количество активных соединений с сервером, также нужно учесть что соединения с php-fpm тоже считаются. Дальше обратите внимание на поля accepted и handled, первое отображает обработанных подключений, второе - количество принятых. Из значения должны быть одинаковыми. Если отличаются значит соединений не хватает. Смотрите примеры, первый снимок проблема, второй - порядок. Для моей конфигурации оптимальной может быть цифра в 200 соединений (всего 800, учитывая 4 процесса):
- multi_accept - позволяет программе принимать несколько соединений одновременно, тоже ускоряет работу, при большом количестве соединений;
- accept_mutex - установите значение этого параметра в off, чтобы сразу все процессы получали уведомление про новые соединения;
Также в секции events рекомендуется использовать директиву use epoll, так как этот самый эффективный метод обработки входящих соединений для Linux, но этот метод применяется по умолчанию, поэтому не вижу смысла добавлять его вручную. Рассмотрим еще несколько параметров из секции http:
- sendfile - использовать метод отправки данных sendfile. Самый эффективный метод для Linux.
- tcp_nodelay, tcp_nopush - отправляет заголовки и тело запроса одним пакетом, работает немного быстрее;
- keepalive_timeout - таймаут поддержания соединения с клиентом, если у вас нет очень медленных скриптов, то будет достаточно будет 10 секунд, устанавливаем значение сколько нужно чтобы пользователь мог быть подключен к серверу;
- reset_timedout_connection - разрывать соединения после таймаута.
- open_file_cache - кэшировать информацию об открытых файлах. Например, open_file_cache max=200000 inactive=120s; max - максимальное количество файлов в кэше, время кэширования.
- open_file_cache_valid - когда нужно проверить актуальность файлов. Например: open_file_cache_valid 120s;
- open_file_cache_min_uses - кэшировать только файлы, которые были открыты указанное количество раз;
- open_file_cache_errors - запоминать ошибки открытия файлов.
- if_modified_since - устанавливает каким образом будут обрабатываться заголовки if-modified-since. С помощью этого заголовка браузер может получить ответ 304 если страница не изменилась с момента последнего просмотра. Возможны варианты - не отправлять - off, отправлять при точном совпадении времени - exact, отправлять если время совпадает точно или больше - before;
Вот как-то так будет выглядеть настройка nginx conf:
user nginx;
worker_processes 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit on;
error_log /var/log/nginx/error.log warn;
load_module "modules/ngx_pagespeed.so";
events {
multi_accept on;
accept_mutex off;
worker_connections 1024;
}
sendfile on;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;
reset_timedout_connection on;
client_body_timeout 10;
keepalive_timeout 65;
include /etc/nginx/sites-enabled.*.conf
3. Настройка http2
Я не буду подробно описывать настройку секции server, потому что делал это уже в статье установка Nginx в Ubuntu и здесь мне нечего добавить, настройка SSL это достаточно обширная тема и тоже будет рассмотрена в отдельной статье. Но чтобы настроить http2 вам нужно иметь уже SSL. Далее, просто подправьте директиву listen в вашей секции server:
listen 194.67.215.125:443 default_server;
listen 194.67.215.125:443 http2 default_server;
Вот таким простым способом можно включить http2 если перед этим была установлена правильная версия Nginx.
4. Настройка PageSpeed
Google Pagespeed - это модуль Nginx, который выполняет различные оптимизации для того, чтобы страницы грузились быстрее, веб-сервер работал эффективнее, а пользователи не чувствовали дискомфорта. Сюда входит кэширование, оптимизация html кода, оптимизация картинок, объединение javascript и css кода и многое другое. Все это выполняется на уровне Nginx, поэтому эффективнее, чем если бы вы это делали в php. Но тут есть один недостаток, модуль удаляет заголовок Last Modified.
Дело в том, что PageSpeed устанавливает очень долгий строк кэширования для всех файлов, а в имя файла добавляет его хэш. Так скорость загрузки ресурсов выходит намного выше, поскольку браузер будет запрашивать файлы только с новым хэшем, а LastModified удаляется чтобы пользователи смогли увидеть изменения в случае если какой-либо файл будет изменен. А теперь рассмотрим как установить модуль. Нам придется собрать его из исходных кодов.
Сначала установите инструменты для сборки, очень важно, если не установите, потом получите ошибку и не будете знать что делать:
yum install wget gcc cmake unzip gcc-c++ pcre-devel zlib-devel
Скачайте и распакуйте исходники Nginx для вашей версии, например, 1.13.3:
wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz
Настройка сервера nginx не включает пере сборку и замену программы из репозитория, мы просто используем эти исходники для сборки модуля. Скачайте и распакуйте исходники PageSpeed:
wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# unzip v1.12.34.2-stable.zip
Скачайте и распакуйте библиотеку оптимизации PageSpeed в папку с исходниками модуля:
cd ngx_pagespeed-1.12.34.2-stable/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz
Скачайте и распакуйте исходники OpenSSL 1.02:
wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz
Теперь нам нужно собрать модуль. Сначала смотрим опции, с которыми собран текущий Nginx:
А теперь переходим в папку с Nginx, подставляем все полученные опции, опцию --add-dynamic-module для PageSpeed, OpenSSL и пробуем собрать:
cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with-ld-opt= --with-openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable ${PS_NGX_EXTRA_FLAGS}
# make
Если все было сделано правильно, то на выходе вы получите модуль ngx_pagespeed.so в папке obj, его нужно скопировать в папку /etc/nginx/modules:
cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so
Создаем папку для кэша:
mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache
Теперь добавьте такую строчку для включения модуля в /etc/nginx/nginx.conf:
load_module "modules/ngx_pagespeed.so";
На данный момент самую большую популярность набрали два веб-сервера. Это Apache и Ngnix. У каждого из них есть свои плюсы и минусы. Apache был разработан еще в 1995 году и при его разработке учитывались не все возможные потребности пользователей, он потребляет много памяти и ресурсов системы, зато он прост в настройке. Nginx был разработан чуть позже в 2002 году уже учитывая ошибки Apache и ориентируясь на максимальную производительность.
Мы не будем подробно вникать в плюсы и минусы этих обоих веб-серверов. У каждого из них своя область применения. В этой инструкции будет рассмотрена установка Nginx Ubuntu 16.04. Хотя я буду говорить об Ubuntu 16.04, все действия подойдут и для других дистрибутивов. Настройка Nginx везде одинакова, только команда установки отличается.
Первым делом нужно установить сам веб-сервер в систему. Программа есть в официальных репозиториях, но ее версия уже немного устарела, поэтому если хотите самую новую версию, нужно добавить PPA:
sudo apt-add-repository ppa:nginx/stable
Сейчас в официальных репозиториях доступна версия 1.10.0, а в стабильной PPA уже доступна 1.10.1. Если для вас версия не нужна можно обойтись и без PPA. Дальше обновите списки пакетов из репозиториев:
И устанавливаем ngnix:
sudo apt install nginx
После того как установка сервера Nginx будет завершена добавим программу в автозагрузку, чтобы она запускалась автоматически:
sudo systemctl enable nginx
Если вы уже сейчас откроете браузер, то увидите работающий nginx, но нам предстоит его еще настроить.
Настройка Nginx Ubuntu
Настройка Nginx Ubuntu намного сложнее чем Apache. Здесь мы не будем рассматривать все опции и возможности программы, а поговорим только об основном. Есть различные конфигурации, в которых Nginx используется в качестве прокси сервера, а основной сервер Apache, но нас это интересовать не будет. Нам нужна установка Nginx как самостоятельного веб-сервера.
Настройки Nginx сильно отличаются здесь есть только один основной файл конфигурации и файлы для виртуальных хостов. Настройка из каждой директории, как в Apache не поддерживается.
- /etc/nginx/nginx.conf - главный файл конфигурации
- /etc/nginx/sites-available/* - файлы конфигурации для виртуальных хостов, проще говоря для каждого сайта.
- /etc/nginx/sites-enabled/* - файлы конфигурации активированных сайтов.
На самом деле файлы конфигурации для виртуальных хостов читаются только из директории sites-enabled, но здесь содержаться ссылки на sites-available. Такая система была придумана, чтобы дать возможность отключать на время те или иные сайты, не стирая их конфигурацию. Все остальные файлы содержат только объявления переменных и стандартные настройки, которые изменять не нужно. Что же касается nginx.conf, то в него включаются все файлы из sites-enables, а поэтому они могут содержать все точно такие же инструкции. А теперь давайте рассмотрим главный файл конфигурации:
sudo vi /etc/nginx/nginx.conf
Как видите файл разделен на секции. Общая структура такова:
глобальные опции
events {}
http{
server {
location{}
}
server {}
}
mail {}
- глобальные опции отвечают за работу всей программы.
- events - эта секция содержит настройки для работы с сетью.
- http - содержит настройки веб-сервера. Должна содержать секцию servier для тонкой настройки каждого сайта.
- server - в этой секции содержится настройка каждого размещенного на веб-сервере сайта.
- location - секция location может находиться только внутри секции server и содержит настройки только для определенного запроса.
- mail - содержит настройки почтового прокси.
Перед тем как перейти к опциям, нужно сказать еще пару слов о синтаксисе строки в конфигурационном файле. Он выглядит вот так:
параметр значение дополнительное_значение... ;
Строка должна обязательно заканчиваться ";", а все открытые скобки { должны быть закрыты.
Теперь, когда вы немного изучили глобальную структуру, можно переходить к рассмотрению самих параметров. Глобальных опций не так уж много:
- user - пользователь, от имени которого будет работать программа.
- worker_processes - устанавливает сколько процессов нужно запускать для параллелизации работы программы, нужно запускать не больше процессов, чем у вас есть ядер. Можно установить параметр auto и тогда программа определит это число сама.
- pid = файл pid программы.
- worker_rlimit_nofile - указывает максимальное количество файлов, которые может открыть программа. Рассчитывается как worker_processes * worker_connections* 2.
С глобальными опциями закончили, их было не так много и они не такие интереснее. Куда интереснее в плане оптимизации опции с секции events:
- worker_connections - количество соединений, которые программа может обрабатывать одновременно на одном процессе. Если умножить worker_process на этот параметр, то мы получим максимальное количество пользователей, которые могут подключиться к серверу одновременно. Рекомендуется устанавливать значение от 1024 до 4048.
- multi_accept - разрешить принимать много подключений одновременно, установите параметр on или off.
- use - способ работы с сетевым стеком. По умолчанию используется poll, но для Linux эффективнее использовать epoll.
- sendfile - использовать метод отправки данных sendfile. Значение on.
- tcp_nodelay, tcp_nopush - отправлять заголовки и начало файла одним пакетом. Значение on.
- keepalive_timeout - таймаут ожидания, перед тем как keepalive соединение будет разорвано, по умолчанию 65, но можно уменьшить до 10 секунд.
- keepalive_requests - максимальное количество keepalive соединений от одного клиента, рекомендовано 100.
- reset_timedout_connection - разрывать соединения после таймаута. Значение on.
- open_file_cache - кэшировать информацию об открытых файлах. Строчка настройки выглядит вот так: open_file_cache max=200000 inactive=20s; max - максимальное количество файлов в кэше, время кэширования.
- open_file_cache_valid - указывает по истечении какого времени нужно удалить информацию из кэша. Например: open_file_cache_valid 30s;
- open_file_cache_min_uses - кэшировать информацию о файлах, которые были открыты как минимум указанное количество раз.
- open_file_cache_errors - кэшировать информацию об отсутствующих файлах, значение on.
Основные параметры рассмотрели. Эти настройки помогут вам получить большую производительность от nginx. Секцию server и location мы рассмотрим в настройке виртуальных хостов.
Настройка сжатия Gzip
Сжатие контента необходимо, чтобы уменьшить размер загружаемых браузером данных. Это ускоряет загрузку сайта, но добавляет дополнительную нагрузку на процессор сервера. Чтобы включить сжатие в секции http нужно добавить параметр:
Эту директиву можно использовать также в секции server, тогда она будет работать только для указного виртуального домена. Дальше настраиваем параметры сжатия настраиваются с помощью следующих опций:
- gzip_min_length - минимальная длина страницы в байтах, при которой нужно использовать сжатие, например, 1000 (1 кб)
- gzip_proxied - нужно ли сжимать проксированые запросы, any говорит, что нужно сжимать все.
- gzip_types - типы файлов, которые нужно сжимать, например: text/plain application/xml application/x-javascript text/javascript text/css text/json;
- gzip_disable "msie6" - в IE 6 сжатие не поддерживается, поэтому отключаем.
- gzip_comp_level - уровень сжатия, доступны варианты от 1 до 10. 1 - минимальное, 10 - максимальное сжатие.
Настройка виртуальных хостов
Как вы знаете, на сервере может размещаться несколько сайтов. Все запросы приходят на ip сервера, а nginx уже определяет на основе домена какой контент нужно выдать. Для того чтобы nginx знал что к какому домену относится нужно настроить виртуальные хосты. Каждый хост принято размещать в отдельном файле. Настройка хоста находится в секции server, но поскольку все файлы из sites-enabled импортируются в секцию http, то логика структуры конфигурационного файла не нарушается.
Рассмотрим пример настройки:
vi /etc/nginx/sites-enabled/сайт.conf
- listen 80 - указывает, что нужно ожидать подключения на порту 80, может также содержать опцию default-server , которая означает, что этот домен будет открывается если домен не был задан в запросе.
- root /var/www/html - директория, в которой находятся файлы сайта.
- index index.html - страница, которая будет открываться по умолчанию.
- server_name - доменное имя сайта.
- access_log - файл для записи лога запросов к серверу, может использоваться как глобально в секции http, так и для определенного типа файлов в location.
- error_log - лог ошибок веб-сервера, может принимать дополнительный параметр, указывающий подробность лога. warn - максимум, crit - только критические ошибки.
Это все основные настройки виртуального хоста, после них он уже будет работать. Но тут есть еще секция location, которая позволяет настроить поведение сервера для определенных директорий и файлов. Синтаксис location такой:
location адрес {}
В качестве адреса может использоваться как прямой запрос относительно корня сервера, так и регулярные выражения. Для использования регулярных выражений перед ним ставится символ "~". Примеры рассмотрим ниже, а пока рассмотрим возможные директивы:
- allow - разрешить доступ к местоположению для пользователей, all - всех, также можно указать ip или подсеть.
- deny - запретить доступ к местоположению, all - для всех.
- try-files - пытается открыть файлы в определенном порядке, открывает первый обнаруженный файл. Например, такая конструкция: $uri $uri/index.html $uri.html =404; сначала пытается открыть $uri, затем index.html, если не найден $uri.html, и аж потом, если ни одного из предложных файлов не существует, выдает ошибку 404.
- expires - задает время кэширования браузером отданного элемента, например, 1d - один день, 2h - два часа, 30s - 30 секунд.
Кроме этих главных директив, здесь могут использоваться и другие. Чтобы получить больше подробностей, смотрите официальную документацию. Рассмотрим пару примеров:
Не выполнять логирование для favicon:
location = /favicon.ico {
log_not_found off;
access_log off;
}
Запретить доступ к файлам, начинающимся с точки:
location ~ /\. {
deny all;
}
Кэшировать обычные файлы на 90 дней:
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires 90d;
Связка nginx, php-fpm, php-apc позволяет ускорить работу сайта при правильной настройке по сравнению с apache и снизить нагрузку на сервер. Особенно это актуально при настройке работы сайтов с большим количеством посещений. Это сочетание компонентов в последнее время становится все более популярным, но настройка при этом достаточно несложная и делается быстро. Давайте посмотрим пример настройки на Debian’e. Настроим nginx с кэшем + php-fpm + php-apc.
Для начала вспомним, что это за компоненты. Nginx — это быстрый и гибкий веб-сервер, который к тому же позволяет использовать кеширование. Php-fpm — это PHP FastCGI Process Manager, менеджер процессов FastCGI для PHP. FastCGI — это бинарный протокол клиент-серверного взаимодействия, позволяющий обрабатывать запросы многопоточно, в отличие от однопоточного CGI. А php-apc — это Alternative PHP Cache, свободный фреймворк для кеширования байт-кода PHP в памяти, что в разы может ускорить выполнение PHP, при неоднократном использовании кода, естественно. Таким образом, ускорение должно быть в нескольких местах. Первое — кэш nginx’а, второе — более быстрая отдача статики при помощи nginx’а по сравнению с apache, третье — кэширование байт-кода PHP, четвертое — более быстрое исполнение кода php при помощи php-fpm по сравнению со связкой apache + mod_php5.
Установка пакетов
Устанавливаем пакеты:
Apt-get install nginx php5-fpm php-apc php5-mysql
Всё необходимое установится по зависимостям
Настройка nginx
После установки пакетов необходимо задать настройки для nginx. Создаем файл настроек nginx для нашего сайта, назовем его «site»
Touch /etc/nginx/sites-available/site
В файл запишем следующее:
Server { # Слушаем 80 порт по IPv4 listen 0.0.0.0:80; # Название сайта (доменное имя) server_name site; # Индексный файл index index.php; # Корневая директория сайта root /var/www/site; # Запрещаем доступ к файлам.htaccess и.htpasswd location ~ /\.ht { deny all; } # Отдача статики location ~ \.(jpg|jpeg|ico|gif|css){ # Отключаем записи об отдаче статических файлов # Это поможет снизить количество операций записи на диск access_log off; expires max; root /var/www/site; } location ~ \.php { include /etc/nginx/fastcgi_params; fastcgi_pass unix:/var/run/php-fpm-site; fastcgi_index index.php; # Включаем кэш nginx, подключаем зону my-cache proxy_cache my-cache; # Таймауты хранения страниц в кэше в зависимости # от ответа сервера. 200 и 302 - 60 минут, 404 - 1 минута proxy_cache_valid 200 302 60m; proxy_cache_valid 404 1m; # Директория для временного хранения proxy_temp_path /var/cache/nginx/tmp; } }
Ln -s /etc/nginx/sites-available/site /etc/nginx/sites-enabled
В файл /etc/nginx/nginx.conf надо добавить кэш, который мы уже записали для использования. В начало секции http вставляем следующую строчку:
Proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my-cache:8m max_size=128m inactive=600m;
Эта строчка означает следующее: директория для хранения кэша — /var/cache/nginx. levels — уровни кэширования 1:2, это уровни вложенности директорий в директории для хранения кэша. Параметр keys_zone определяет название и объем зоны кэша (зон может быть несколько). Зона размером 1 мегабайт может хранить 8000 ключей. Параметр max_size определяет максимальный объем кэша, когда кэш достигнет этого объема, то старые файлы из кэша будут удаляться, чтобы освободить место. Если данные не будут запрошены из кэша в течение времени, указанного в параметре inactive (в нашем случае 600 минут), то они будут удалены из кэша. Если параметр inactive не указан, по умолчанию время составляет 10 минут.
Настройка php-fpm
Настройки php-fpm находятся в директории /etc/php5/fpm. В этой директории есть поддиректория pool.d, в которой хранятся файлы для работы с сайтами. Нам нужно создать файл для нашего сайта. Назовем его site.conf
Touch /etc/php5/fpm/pool.d/site.conf
В этот файл записываем следующее:
# Сокет-файл для обмена данными с nginx listen = /var/run/php-fpm-site.sock # Максимально доступное в системе количество соединений listen.backlog = -1 # Владелец сокета и группа владения listen.owner = www-data listen.group = www-data # Права, устанавливаемые при создании сокета listen.mode = 660 user = www-data group = www-data # Количество процессов будет контролироваться динамически pm = dynamic pm.max_children = 30 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 5 pm.max_requests = 50 env = site env = /usr/local/bin:/usr/bin:/bin env = /tmp env = /tmp env = /tmp
Теперь можно запускать php-fpm командой
Service php5-fpm start
И после этого так же запустить nginx
Service nginx start
Давайте создадим директорию /var/www/site, если она еще не создана:
Mkdir -p /var/www/site
А в этой директории создадим файл /var/www/site/index.php со следующим содержимым:
Теперь в браузере откроем наш сервер по доменному имени. Например, «http://site». Должна открыться страница с информацией о сервере. Там же перечислены все модули, которые используются. В этом списке должен присутствовать модуль apc, и его статус должен быть «Enabled».
Настройка php-apc
Конфигурационный файл apc находится по следующему пути: /etc/php/fpm/conf.d/20-apc.ini
В принципе, с настройками по умолчанию этот модуль уже можно использовать, но если хотите настроить его более тонко, то описание всех параметров можно посмотреть .
В целом конфигурация готова, можно разворачивать сайт и настраивать все эти компоненты более детально, в зависимости от того, как устроен сайт и какая статистика будет накоплена в процессе его работы.
От стабильной и быстрой работы сервера зависит судьба сайта. Его медленная работа и частые падения способны отпугнуть как посетителей, так и поисковые системы. Последние ещё и понизят рейтинг тормозящего сайта в результатах поиска и он окажется не в топ-10, а, скажем, в топ-100 по всем запросам.
Использование связки nginx и php-fpm для обслуживания сайтов позволяет увеличить скорость их работы, а также стабильность системы в целом. К тому же, отказавшись от использования apache, мы несколько упрощаем систему и даже защищаем её. Ведь если нет apache, то злоумышленник не сможет использовать, например, файл.htaccess для своих целей.
Связку nginx+php-fpm настраивать довольно легко и она поддерживается многими популярными CMS: WordPress, MODX, DLE, различными фреймворками. Всё это способно работать и без громоздкого apache.
При установке веб-сервера, не обойтись без создания пользователей. В идеале, для каждого сайта должен быть создан отдельный юзер. Так мы сможем защитить другие сайты, если один из пользователей будет взломан. Примеры в этой статье написаны с учётом того, что пользователей вы создали по .
Для начала установим базовые модули: php-fpm, mysql, curl, GD. Всё остальное — по индивидуальной необходимости.
# aptitude install nginx php5-fpm php5-mysqlnd php5-curl php5-gd
Конфигурационные файлы располагаются в каталоге /etc/php5/fpm/ .
Изначально в php-fpm есть только один пул по имени www. Мы будем использовать его в качестве основы для других пулов.
Откроем конфигурационный файл /etc/php5/fpm/pool.d/www.conf , рассмотрим некоторые переменные и подберём для них значения.
Первая переменная — это имя пула. Оно заключается в квадратные скобки и не может совпадать с именем любого существующего в системе пользователя.
User = username group = www-data
Указываем, что пул должен работать в качестве unix-сокета. Переменная $pool будет заменена на имя.
listen = /var/run/php-$pool.sock
Определяем использование статического режима, при котором во время запуска fpm создаётся определённое количество процессов пула. Они обслуживают все поступающие запросы.
Почему именно такой выбор? :) Это самый экономный вариант. Каждый процесс пула будет занимать объём оперативной памяти, выделенный переменной memory_limit плюс несколько мегабайт на подключённые модули, кэш и т.п. При статичном варианте все запросы будут обрабатываться только созданными процессами, а новые порождаться (и занимать драгоценную память) не будут. В итоге получим фиксированное потребление памяти.
Указываем необходимое количество процессов, обслуживающих запросы. Подбирается в зависимости от загруженности.
pm.max_children = 3
Каталог для размещения временных файлов:
Php_admin_value = "/var/www/username/tmp"
Каталог для хранения файлов сессий:
Php_admin_value = "/var/www/username/sessions"
По соображениям безопасности, доступ к этим каталогам должен быть только у пользователя, с правами которого запускается пул php-fpm. Также не следует использовать один каталог и для хранения файлов сессий, и для временных файлов.
Ограничение памяти для выполнения скриптов следует подбирать, исходя из требований сайта. Для начала:
Php_admin_value = 50M
Укажите обязательный параметр, который устраняет уязвимость :
Php_admin_value = 0
Переменные sendmail_path и open_basedir не указываются специально. Они будут переданы в качестве параметров fast-cgi в конфигурационном файле nginx. Таким образом, для каждого конкретного сайта можно определить свою настройку. :)
После того, как все необходимые параметры прописаны, следует перезагрузить конфигурацию php-fpm командой:
# service php5-fpm reload
Обработка php скриптов посредством nginx
Остаётся настроить nginx для работы с php-fpm. Готовый конфиг
Server { server_name example.com ; listen 80; access_log /var/log/nginx/example.com .access.log; error_log /var/log/nginx/example.com .error.log; charset utf-8; index index.php; root /var/www location / { try_files $uri $uri/ /index.php$args; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/run/php-www.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i [email protected]"; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/"; } }
example.com заменяем на свой домен.
Описание параметров :
try_files $uri =404; отобразит ошибку 404 в браузере пользователя, вместо сообщения no input file specified , в случае, когда данная ошибка имеет место.
fastcgi_pass — путь к сокету php-fpm.
Fastcgi_pass unix:/run/php-www.sock;
Следующая переменная устанавливает путь к sendmail и параметр, указывающий адрес электропочты администратора сайта. Замените [email protected] на что-то своё.
Fastcgi_param PHP_VALUE "sendmail_path=/usr/sbin/sendmail -t -i [email protected]";
Перечисляем каталоги для open_basedir: каталог с сайтом, каталог для сохранения временных файлов, каталог для файлов сессий.
Fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/";
Если требуется передать несколько параметров, до делать это следует так:
Fastcgi_param PHP_ADMIN_VALUE "sendmail_path=/usr/sbin/sendmail -t -i [email protected]\nopen_basedir=/var/www/example.com/:/var/save_path/:/var/tmp_dir/";
Как можно заметить, параметры разделяются при помощи переноса строки: \n .
Сохраняем все проделанные изменения и перезапускаем nginx.
# service nginx reload
Вконтакте