Данная статья посвящена оптимизации сайтов, а именно изменению работы PHP на FastCGI (nginx + php-fpm). Это необходимо, если Вы используете режим FastCGI (как модуль apache), CGI.
Если Вы используете режим LSAPI на нашем обычном виртуальном хостинге, то он также является достаточно производительным. Для использования FastCGI (nginx + php-fpm) необходимо заказать линейку мощных тарифов, подходящих для работы на любых CMS.
Внимание! Для перевода сайта на CMS WordPress, Joomla, OpenCart, Bitrix необходимы дополнительные действия, и сейчас мы их разберем.
Внимание! Данный мануал подходит для VPS серверов с панелью управления ISPmanager Lite 5. Для изменения на тарифах мощного виртуального хостинга свяжитесь, пожалуйста, с отделом продаж.
3) Выбираем пункт «Версия PHP (PHP-FPM)». В нем необходимо выставить такую же версию php, какая сейчас стоит у Вас на сайте. После выставления, нажимаем «Ok«.
Выставляем такую же версию, как у нас стояла на режиме apache
4) После этого возвращаемся во вкладку www-домены и меняем прежний режим работы на FastCGI (nginx + php-fpm) Сохраняем изменения.
Теперь мы можем попробовать зайти на сайт и проверить, все ли ссылки на сайте работают корректно, но, как правило, работает только главная страница, а все остальные отдают 404 ошибку.
Если у Вас похожая ситуация, то необходимо прописать дополнительный редирект.
5) Для этого в той же вкладке www-домены выбираем домен и нажимаем на кнопку «Конфиг».
Далее, в зависимости от Вашей CMS, выбираем один из вариантов:
a) Если у Вас WordPress, Joomla
Под ней необходимо добавить наш редирект:
В конечном итоге, у нас получится такой блок:
б) Если у Вас Битрикс
Редирект необходимо будет прописать после блока location @php <, и выглядеть он будет по другому:
Должно получиться вот так:
в) Если у Вас Opencart, то редирект необходимо вставить в блок location / :
ВАЖНО. Если у Вас на сайте используется SSL сертификат, то таких блоков у Вас будет два в разделе «конфиг». Необходимо прописать отдельно для http блока, и отдельно для https блока.
После того, как Вы прописали редирект, сохраняем конфиг и проверяем работу сайта.
Если по каким-то причинам Вам не удалось перейти на FastCGI (nginx + php-fpm), свяжитесь с нашей техподдержкой, и мы обязательно Вам поможем.
Битрикс в связке Nginx+PHP-FPM, настройка ЧПУ, а так же композитный кэш с отдачей через nginx. Доработанная конфигурация
Цель: Предоставить конфигурацию виртуального сервера Nginx для работы Битрикс-cms в связке Nginx+PHP-FPM. Который в прочем подойдёт и для связки Nginx+Apache2, с небольшими доработками.
Cтатей на эту тему достаточно, но если смотреть не официальные, то там как правило содержатся ошибки, а в официальных полно if которые в Nginx использовать не желательно. Надеюсь после того как я выложу данный конфиг к связке Nginx+PHP-FPM станут относиться серьёзнее.
Я покажу реализацию отдачи файлового композитного кэша. В целом отдача с memcached делается по аналогии. В конфигурации отдачи файлового кэша я насчитал 11 if, от которых я и избавился переделав их на map.
Начну с упрощённого варианта ЧПУ для тех кому нужна просто связка Nginx+PHP-FPM без отдачи композитного кэша через Nginx. Подразумевается что секция server уже настроена, с доменными именами и передачей в php-fpm.
Как не удивительно смотря на те полотна конфигов которые мне попадались, этого достаточно чтобы битрикс корректно заработал. Если нужен редирект с index.php и index.html на без, то нужно ещё дописать вот эту строку:
К сожалению тут достойной замене if нет. Но данная строчка работает не создавая проблем.
Хочу подчеркнуть что это именно минималистичная конфигурация без правил для статики, сжатия, и я там прикрыл только файлы композитного кэша от прямого доступа. Конфигурация которая прикрывает определённые места от прямого доступа через nginx довольно индивидуальна. У меня есть вот такой набор который может кому-то подойти. Но использовать нужно аккуратно с осознанием дела. Учитите что внесение данных локейшенов в свою конфигурацию может привести к неработоспособности сайта или части его функций.
Ну и конечно пример location для статических файлов
Теперь перейдём к конфигу для работы композита с отдачей файлов кэша через nginx. Первым делом необходимо определить можно ли отдавать данному запросу композитный кэш или его нужно отправить на обработку через php. Для этого в Nginx в секции http добавим несколько map, а так же несколько директив:
Далее уже непосредственно в секции server прописываем
Ну и для понимания как примерно будет выглядеть минимальная конфигурация секции server
Для чего эта заметка, ведь похожих уже полно? Если кратко, то когда я взялся настроить связку пришлось перечитать огромное количество документации и разных статей, все сразу и в одном месте найти не получилось. Данная статья попытка систематизировать накопленные знания, а также максимально подробная помощь тем, кто только начинает осваивать nginx.
В качестве теста решил перевести все свои сайты на nginx, до этого все работало на Apache из состава ZendServerCE. Интересно было пробовать насколько сложно будет полностью переехать на новый для себя веб-сервер, ведь используется несколько CMS (DLE, WordPress, самописныеCMS).
Имеем свежеустановленный сервер Debian 6 в минимальной установке из netinstall. И так поехали.
1. Подготовительные работы
Добавляем необходимые в дальнейшем репозитории в /etc/apt/sources.list
Из бэкпортов ставим свежее ядро (по желанию)
Ставим необходимые пакеты
2. Настройка Nginx
Несмотря на то, что конфигурация Nginx состоит из нескольких файлов, сам nginx начинает читать единственный файл: /etc/nginx/nginx.conf, все остальные подключаются директивой include.
Настройка виртуального домена
Создаем директории для доменов и шаблонов
Настройка шаблонов.
Общий шаблон nano /etc/nginx/templates/default
Шаблон подключения обработки php nano /etc/nginx/templates/php
Шаблон подключения обработки Perl nano /etc/nginx/templates/perlcgi
Удаляем стандартный default, если есть Применение новых параметров
Если все верно, то nginx начинает работать с новой конфигурацией, если нет — работа продолжается со старой, рабочей конфигурацией.
Проверка работоспособности php. Создадим файл test.php в корневом каталоге сайта (в нашем случае это /var/www/htdocs/) следующего содержания:
После чего переходим в браузере IP/test.php, если все верно — получаем параметры php на сервере, после чего удаляем этот фаил для безопасности.
Проверка работоспособности Perl. Создадим файл test.cgi в корневом каталоге сайта (в нашем случае это /var/www/htdocs/) следующего содержания:
После чего переходим в браузере IP/test.cgi, если все верно — получаем «Hello world».
Если все работает, то на этом этапе мы имеем рабочий веб сервер с поддержкой php и perl скриптов, дальше опишу некоторые нюансы донастройки отдельных его частей.
3. Настройка PHP-FPM
В Debian конфигурация PHP-FPM состоит из 2х частей: глобальной (/etc/php5/fpm/php-fpm.conf) и настройки пулов (/etc/php5/fpm/pool.d/*.conf). В данном примере глобальные настройки мы трогать не будем, а вот на настройке пулов остановимся чуть подробнее.
Пулы
Для начала разберёмся зачем нужны пулы. В случае разных требований сайтов к PHP-окружению (различные параметры php.ini, разное число обработчиков и т.д.) может потребоваться создание дополнительных пулов. Данная операция в PHP-FPM весьма тривиально:
Настройка каждого пула в Debian представлена своим файлом в каталоге /etc/php5/fpm/pool.d/. По умолчанию системе есть единственный пул «www» (файл: /etc/php5/fpm/pool.d/www.conf) именно его настройкой мы и займёмся.
Workers (обработчики)
Самая спорная часть в настройке пула, это количество обработчиков php-скриптов. На первый взгляд, кажется, что чем больше обработчиков, тем эффективней обрабатываются php-скрипты. Но это не так! Во-первых: большое число обработчиков расходует больше памяти (а для нашего сервера память весьма критичный ресурс), во-вторых: если обработчиков очень много и, так случилось, что все они реально заняты работой, то у сервера может просто не хватить ресурсов на другие задачи (даже есть вероятность, что подключение по SSH станет практически не возможным).
В идеале число обработчиков должно быть таким, что даже при стрессовой нагрузке LoadAvarage системы оставался в разумных пределах. Т.е. пусть лучше при высокой нагрузке пользователи периодически получают сообщения о недоступности сервиса (ошибка 502: Gateway timeout), чем полная недоступность сервера даже для администратора.
И так немного подредактируем стандартный пул nano /etc/php5/fpm/pool.d/www.conf
Оптимальное число обработчиков зависит от ресурсов сервера, сложности php-скриптов, нагрузки, создаваемой на mysql-сервер и т.д. В любом случае оптимальное число обработчиков нужно подбирать на основе тестирования работы сайта. Методика тестирования неплохо описана тут, повторяться не буду.
Добавление пула
При увеличении числа обслуживаемых сайтов может понадобиться создание дополнительных пулов, для настройки различных параметров каждому сайту — своё. Данная операция в php-fpm, на наш взгляд, весьма тривиальна: Нужно скопировать файл /etc/php5/fpm/pool.d/www.conf под новым именем (для примера назовём его newpool.conf) Дать новому пулу имя: находим вверху нового файла строку [www] (имя первого пула) и меняем на [newpool] Меняем адрес подключения к php-fpm (директива «listen»). Т.к. каждый адрес должен быть уникален, то нужно изменить:
Или, в случае использования unix-сокетов,
Номера портов и путей к unix-сокетам во всех пулах должны быть разными!
Для применения параметров после изменения php.ini (для PHP-FPM полный путь к файлу выглядит так: /etc/php5/fpm/php.ini) или собственных настроек PHP-FPM требуется перезапуск сервиса
4. Установка phpmyadmin
Загрузим стабильную версию phpmyadmin с сайта www.phpmyadmin.net/home_page/downloads.php
Распакуем сразу в нужную дирректорию и дадим нужные права.
Скопируем файл с примером конфигурации и приведем его к следующему виду (сгенерировать blowfish_secret можно здесь):
Затем создаем базу данных и пользователя необходимые для работы phpMyAdmin:
Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04
Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.
В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.
Технологии которые будут использованы в статье: nginx, php-fpm.
Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе. Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.
Установка пакетного менеджера aptitude, обновление индекса и пакетов
Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).
Установка и настройка nginx (версия >= 1.10.0)
Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.
Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:
Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.
Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).
Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.
В случае установки nginx «с нуля», именно «с нуля», так как при удалении nginx командой или конфигурационные файлы остаются и если вы вдруг будете не понимать, почему nginx не работает и захотите его переустановить (обычно к такому прибегают начинающие пользователи Linux), то и после переустановки он не будет корректно работать, из-за того что в старых конфигурационных файлах (они не удаляются после удаления командой remove) прописаны неверные настройки, их придется удалить, либо настроить верно, только тогда nginx заработает.
В этом каталоге будет по умолчанию один файл, с названием default. В нем будет конфигурационный файл с примером, с комментариями, его вы можете изучить на досуге, а можете и вовсе удалить (всегда можно обратиться к официальной документации).
Создадим свой конфигурационный файл, который будет соответствовать названию домена нашего локального сайта (или реального, если уже знаете его название). Это удобно, в будущем, когда будет много конфигурационных файлов, то это избавит вас от путаницы в них. У меня этот файл будет называться project.local.
Посмотрим что получилось.
Теперь откроем его в редакторе, я открою его в nano.
Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.
Смотрите комментарии прям в конфигурационном файле.
Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.
Если видим такую информацию как на скриншоте, значит у нас все верно, может продолжать настройку. Если вы получаете какие-либо ошибки, стоит перепроверить конфигурационный файл.
Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.
Посмотрим на наш созданный симлинк.
Чтобы убедиться что мы делаем еще все верно опять запустим команду.
Если все ок, едем дальше.
Файл hosts
Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.
Открываем файл в редакторе nano.
У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.
Не забываем сохранить файл. На этом настройка файла hosts закончена.
Установка php-fpm (>=7.0)
Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.
Убеждаемся что все ок. Стартуем php-fpm.
Если будете править конфиги, то не забывайте рестартовать демон. Это делает так. Но нам это не потребуется.
На этом установка и настройка php-fpm закончена. Правда, это все. Это не магия, путь до сокета php-fpm у нас уже был прописан в конфигурационном файле. Конечно, вам могут понадобиться какие-либо расширения php для разработки личных проектов, но их вы можете поставить по мере того как они будут требоваться.
Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.
Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.
На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.
Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.
Выставляем такую же версию, как у нас стояла на режиме apache
