Настройка php fpm: Настройка PHP-FPM в Linux

Настройка PHP-FPM для повышения производительности + Low Memory

PHP-FPM имеет конфигурацию по умолчанию, которая использует больше памяти, чем это необходимо. Она имеет запасные PHP-FPM процессы, готовые запускаться, занимая память в случае, если есть PHP код в обработки. Хотя это и не проблема, если у вас есть тонны оперативной памяти, это может быть проблемой для низкой VPS RAM и если вы используете агрессивное кэширование страниц, то это память используется без необходимости, которая может быть использована для MariaDB (MySQL) или для других важных процессов. Это руководство объясняет, как настроить конфигурацию Nginx с PHP-FPM работающем на PHP 7.0, чтобы использовать как можно меньше оперативной памяти, как это возможно.

Настройка PHP-FPM для повышения производительности + Low Memory

Откройте файл конфигурации PHP-FPM для PHP 7.0.

sudo nano /etc/php/7.0/fpm/pool.d/www.conf

Настройте следующие значения, как показано ниже, обратите внимание на ; перед pm. start_servers, pm.min_spare_servers и pm.max_spare_servers.

pm = ondemand означает, что дочерние процессы в PHP-FPM будут порождаться только при необходимости

pm.max_children это максимальное количество дочерних процессов, которые будут разрешены, 50 является достаточно либеральным, но если вы видите в своем архиве журналов что количество дочерних процессов превысило максимальное значение,  то необходимо увеличить это значение

pm.process_idle_timeout убивает дочерние процессы после того, как они бездействовали в течение 10 секунд

pm.max_requests устанавливает максимальное количество запросов PHP для каждого дочернего процесса

pm = ondemand

; Число дочерних процессов, которые будет создано, когда pm установлен в 'static' и
; Максимальное число дочерних процессов, когда pm установлен в 'dynamic' и 'ondemand'.
; Это значение устанавливает ограничение на количество одновременных запросов, которые будут
; запускаться.  Эквивалент директивы ApacheMaxClients в mpm_prefork.
; Эквивалентная переменная среды PHP_FCGI_CHILDREN в оригинальном PHP
; CGI. Ниже, по умолчанию основаны на сервере без использования значительных ресурсов. Не
; забудьте настройки часов.* чтобы соответствовать вашим потребностям.
; Примечание: используется, когда pm установлен в 'static', 'dynamic' или 'ondemand'
; Примечание: это значение является обязательным.
pm.max_children = 50

; Число дочерних процессов, созданных при запуске.
; Примечание: используется только тогда, когда pm установлен в "dynamic"
; Значение по умолчанию: min_spare_servers + (max_spare_servers - min_spare_servers) / 2
;pm.start_servers = 2

; Требуемое минимальное число неактивных процессов сервера.
; Примечание: используется только тогда, когда pm установлен в "dynamic"
; Примечание: обязательное, когда pm установлен в "dynamic"
;pm.min_spare_servers = 1

; Требуемое максимальное число неактивных процессов сервера. 
; Примечание: используется только тогда, когда pm установлен в "dynamic"
; Примечание: обязательное, когда pm установлен в "dynamic"
;pm.max_spare_servers = 3

; Число секунд, по истечении которых бездействующий процесс будет убит.
; Примечание: используется только тогда, когда pm установлен в 'ondemand'
; Значение по умолчанию: 10s
pm.process_idle_timeout = 10s;

; Число запросов после которых дочерний процесс будет перезапущен.
; Это может быть полезно во избежания утечек памяти в 3-й партии библиотек. Для
; бесконечной обработки запроса укажите '0'. Эквивалент PHP_FCGI_MAX_REQUESTS.
; Значение по Умолчанию: 0
pm.max_requests = 500

Проверьте правильность вашего синтаксиса конфигурации PHP-FPM

php-fpm7.0 -t

Вы должны увидеть, что конфигурация действует

[01-Jun-2017 15:51:34] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

Теперь вы можете перезапустить php7. 0-FPM

sudo service php7.0-fpm restart

Вы можете увидеть, что объем оперативной памяти используется значительно меньше.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Настройка nginx + php-fpm в Debian/Ubuntu

Nginx — это HTTP-сервер. По сравнению с apache он более отказоустойчив, способен выдержать большое количество соединений. В основном применяется на продакшн серверах, почему-то его редко настраивают для локальной разработки, хотя это не сложнее, чем настроить apache + php.

Но различия все таки есть. Начнем с того, что php может работать с nginx в режиме fastCGI,  в то время как с apache как в режиме в fastCGI, так и как модуль апача. Кроме того, придется отдельно настраивать rewrite, basic authentication и т.д. (.htaccess — фича апача).

Но заставить работать в простейшем случае — несложно =)

Итак, нужно поставить, собственно, сам nginx, php (если еще не стоит) и php-fpm:

aptitude install nginx php5 php5-cli php5-fpm

Nginx и php-fpm должен добавиться в автозапуск и стартонуть, но если внезапно этого не произошло, то

service nginx start
service php5-fpm start

Можно проверить наличие в автозапуске с помощью, например, rcconf.

(Хотя еще не сконфигурирован ни nginix, ни php-fpm, в будущем все равно придется перезапустить).

Конфигурация Nginx

Сам nginx должен работать на конфигурации

nano /etc/nginx/nginx.conf

«с коробки». На что стоит обратить внимание — это на параметр

user www-data;

Он определяет, с какого пользователя будет запускаться Nginx.

Также следует проверить, подключается ли конфигурация модулей и хостов. Должны (как правило, в конце) быть строчки вроде:

include             /etc/nginx/conf.d/*.conf;
include             /etc/nginx/sites-enabled/*;

Теперь нужно создать конфигурацию хоста:

nano /etc/nginx/sites-available/your_site.conf

server {
    listen   80;
    server_name www.site.net site.net;
    root /usr/share/nginx/www/default;
    index index.html index.htm;

access_log /var/log/nginx/site.log; error_log /var/log/nginx/site.log;

# Дальше настройка php location ~ .php$ { fastcgi_split_path_info ^(. +.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; } }

(можно посмотреть в /etc/nginx/sites-available.default)

Таким образом, сконфигурировали работу с php-fpm через сокет.

Осталось подключить конфигурацию:

ln -s /etc/nginx/sites-available/your_site.conf /etc/nginx/sites-enabled/your_site.conf

Теперь

service nginx reload

И вуаля, все должно работать — мы настроили сервер nginx. P.S. Не забудьте подправить /etc/hosts, если это необходимо

Используем ‘pm static’ для максимальной производительности

Давайте кратко рассмотрим, как лучше настроить PHP-FPM для высокой пропускной способности, низкой задержки и более стабильного использования процессора и памяти. В большинстве дефолтных настроек PHP-FPM есть строка с PM (process manager), установленным в dynamic, а также рекомендации по использованию ondemand, в том случае если вы столкнулись с проблемами доступной памяти. Однако, давайте взглянем в документацию на php.net и сравним оба варианта управления, а также сравним с моей любимой настройкой под высокую посещаемость… pm = static:

pm = dynamic – количество дочерних процессов устанавливается динамически, основываясь на следующих директивах: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.

pm = ondemand – процессы плодятся по требованию (при необходимости, в отличие от динамического варианта, где pm.start_servers запускаются при запуске сервиса).

pm = static – количество дочерних процессов фиксировано директивой pm.max_children.

…вы можете посмотреть полный список директив php-fpm.conf для получения дополнительной информации.

Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor

Это может показаться немного не по теме, но я надеюсь связать его с нашей оптимизацией PHP-FPM. Да, все мы когда-то натыкались на проблемы с производительностью процессора, будь то ноутбук, виртуальная машина или выделенный сервер. Помните масштабирование частоты процессора? (CPUFreq governor) Эти параметры, доступные на *nix и Windows, могут повысить производительность и отзывчивость системы путем изменения настройки CPU governor с ondemand на performance. Сейчас давайте сравним описания и поищем сходства:

Governor = ondemand – Динамически увеличивает/уменьшает тактовую частоту процессора в зависимости от загруженности системы. Выводит до максимальной частоты, а потом уменьшает по мере увеличения времени простоя.

Governor = conservative – Похож на ondemand, но более экономный (предпочтение отдаётся меньшим тактовым частотам). Частота растёт более плавно.

Governor = performance – Поддерживает процессор(ы) на максимальной тактовой частоте.

… для дополнительной информации см. полный список настроек CPUFreq governor.

Заметили сходство? Я хотел сначала использовать это сравнение, чтобы более наглядно и лучше описать рекомендацию использовать pm static для PHP-FPM в качестве вашего первого выбора.

Настройка performance в CPU governor – это довольно безопасный прирост производительности, потому что это почти полностью зависит от предела процессора вашего сервера. Но есть несколько побочных эффектов (при постоянном удерживании частоты вашего процессора на 100%) – такие, как нагрев, время автономной работы (ноутбук) и другие. Однако это действительно самый быстрый параметр для вашего процессора.

Использование

pm = static для максимальной производительности вашего сервера

Настройка pm = static в PHP-FPM сильно зависит от того, сколько свободной памяти на сервере. В основном, если вы страдаете от нехватки памяти сервера, то pm ondemand или dynamic могут оказаться лучшими вариантами. С другой стороны, если у вас достаточно свободной памяти, вы можете избежать большей части накладных расходов менеджера процессов, установив pm static до максимальной емкости сервера. Другими словами, когда вы делаете расчёты, pm.static нужно установить на максимальное количество PHP-FPM процессов, которые могут выполняться без создания проблем доступности памяти или кеша; однако, не так высоко, чтобы перегрузить процессор(ы) и иметь кучу отложенных операций PHP-FPM-а.

На скриншоте выше, у этого сервера установлен pm = static и pm.max_children = 100, которые используют максимум около 10 ГБ из 32 ГБ установленных. Обратите внимание на выделенные столбцы, которые говорят сами за себя. В момент этого скриншота было около 200 активных пользователей (за последние 60 секунд). При таком уровне пользователей, около 70% из дочерних процессов PHP-FPM по-прежнему простаивает. Это означает, что PHP-FPM настроен так, что всегда использует максимум возможности ресурсов вашего сервера вне зависимости от текущего трафика. Процессы, находящиеся в простое, остаются «онлайн», ожидая всплеска трафика, чтобы мгновенно ответить, а не ждать PM пока он насоздаёт дочерних процессов, а потом ещё будет убивать их после того, как истечёт pm.process_idle_timeout. В моих настройках pm.max_requests установлен чрезвычайно высоко, т. к. это боевой сервер, в котором не должно быть утечки памяти в PHP. Вы можете использовать pm.max_requests = 0 при статическом режиме, если у вас есть 110% уверенности в ваших нынешних и будущих PHP-скриптах. Однако, рекомендуется перезапускать скрипты время от времени. Устанавливайте ваше количество запросов до перезапуска в наибольшее значение, чтобы избежать оверхеда PM-а. Например, как минимум pm.max_requests = 1000… основывайтесь на вашем количестве pm.max_children и количестве запросов в секунду.

На скриншоте используется линуксовый top. Тут отображаются не все процессы, а только та часть, что вместилась в ваше терминальное окно. В нашем случае отсортированных по %CPU (потреблению процессора). Чтобы увидеть все 100 PHP-FPM процессов, вы можете использовать что-то вроде этого:

top -bn1 | grep php-fpm

Когда использовать pm

ondemand и dynamic

Используя режим dynamic, вы можете наткнуться на подобные ошибки:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Вы можете попытаться увеличить/изменить настройки и по-прежнему видеть ту же ошибку. Подобная ситуация описана в этом вопросе на Serverfault. В таком случае, pm.min была слишком низкой, а т. к. трафик сильно колеблется, режим dynamic достаточно сложно настроить правильно. Общий совет: используйте ondemand, как советуют в этом же вопросе. Однако что еще хуже, т. к. ondemand будет завершать процессы в простое вплоть до 0 когда мало трафика, то после вы получите настолько много накладных расходов, насколько скакнёт трафик. Если, конечно, вы не установите время ожидания чрезвычайно высоким. В этом случае вам просто нужно использовать pm = static + высокий pm.max_requests.

Несмотря на это, всё-таки режим dynamic и особенно ondemand может спасти вас когда у вас есть несколько PHP-FPM Pool-ов. Например, при хостинге нескольких cPanel-аккаунтов или нескольких сайтов под разными pool-ами. У меня есть сервер, к примеру, со 100+ аккаунтами cPanel и около 200+ доменами, и для режима static или даже dynamic было бы невозможно поддерживать хорошую производительность. И только режим ondemand справляется с этим хорошо, т. к. более двух третей из веб-сайтов имеют маленький трафик, а с ondemand это значит, что все «дети» будут завершены, экономя тонны серверной памяти! К счастью, разработчики cPanel это поняли и теперь по умолчанию стоит ondemand. Ранее с динамическим режимом по умолчанию, использовать PHP-FPM на общих серверах было не вариантом. Многие использовали suPHP , потому что dynamic-режим съедал память даже в простое PHP-FPM Pool-ов. Вероятно, если вы имеете хороший трафик, вы не будете размещены на сервере с большим количеством PHP-FPM Pool-ов (shared hosting).

Заключение

Когда дело доходит до PHP-FPM, раз вы начали получать серьезный трафик, то режимы ondemand и dynamic могут ограничить пропускную способность из-за свойственного оверхеда. Исследуйте вашу систему и установите количество процессов в наибольшее, с которым справится ваш сервер. Начните с pm.max_children, установленным на основе максимального использования режимов dynamic или ondemand, а затем увеличивайте до точки, где память и процессор остаются не перегруженными. Вы заметите, что с pm = static, т. к. вы держите всё в памяти, всплески трафика со временем будут меньше влиять на всплески загрузки процессора, а показатели загрузки и средней загрузки станут более сглаженными. Средний размер вашего PHP-FPM-процесса будет зависеть от конкретного веб-сервера, требующего ручной настройки, вот почему автоматизированные режимы – dynamic и ondemand – являются более популярными рекомендациями. Надеюсь, это была полезная статья.

Веб-сервер на основе Nginx и PHP-FPM

Существуют различные схемы построения веб-серверов для передачи данных по протоколу HTTP. Среди них достойное место по производительности занимают схемы с использованием «Nginx» в качестве внешнего (кэширующего, front-end) сервера. «Nginx» разработан для отдачи статических данных, при этом, он показывает высокое быстродействие и нагрузочную способность (см. Nginx vs Cherokee vs Apache vs Lighttpd), генерировать же динамическое содержимое он не способен. Поэтому, он часто применяется в связке с внутренним (back-end) сервером для обработки динамических данных которые потом отдаются «Nginx» как статические без участия внутреннего сервера. В качестве внутреннего сервера может применяться «Apache2» или, что и рассматривается в данной статье, «PHP-FPM».

В данной статье рассматривается установка и настройка связки Nginx и PHP-FPM на локальной ЭВМ, если требуется работа на выделенном сервере, то следует обратится к более серьезным инструкциям или/и непосредственной помощи специалистов

Сервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале

sudo apt-get install nginx

Установку же «PHP-FPM» можно произвести, например, командой

sudo apt-get install php5-cli php5-common php5-mysql php5-suhosin php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt

Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:

1. Должно быть запрещено выполнение PHP-кода из открытых для записи директорий. Например, директории для загрузки аватаров, файлов или директории доступные также FTP-серверу, который позволяет произвести запись в них.

2. Следует следить за логами работы сервера, это позволяет выявить попытку взлома как можно раньше и минимизировать угрозу дальнейшего ущерба.

3. Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости.

4. Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов).

Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами

sudo service nginx stop
sudo service php5-fpm stop

Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой

sudo gedit /etc/php5/fpm/php.ini

после чего, найти строчку содержащую «cgi. fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)

;cgi.fix_pathinfo = 1

и привести её к виду

cgi.fix_pathinfo = 0

И сохранить изменения. Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).

Далее, необходимо отрыть для редактирования файл «/etc/php5/fpm/pool.d/www.conf», например, командой

sudo gedit /etc/php5/fpm/pool.d/www.conf

найти строчку с параметров «security.limit_extensions» и привести её к виду

security.limit_extensions = .php .php3 .php4 .php5

Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду

listen = /var/run/php5-fpm.sock

Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой

sudo service php5-fpm restart

Можно убедится в том, что права доступа к сокету установлены верно:

ls -la /var/run/php5-fpm.sock

Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,

srw-rw---- 1 www-data www-data 0 May  2 16:36 /var/run/php5-fpm.sock

Основные настройки «Nginx» хранятся в файле «/etc/nginx/nginx.conf». Настройки базового сайта хранятся в файле «/etc/nginx/sites-available/default». Базовый конфигурационный файл сайта принято помещать в папку «/etc/nginx/sites-available/» и затем включить его путём добавления символической ссылки на этот файл в папке «/etc/nginx/sites-enabled/». Например, создадим конфигурационный файл для сайта с доменным именем (для примера выбрано «example.com») в названии для удобства

sudo touch/etc/nginx/sites-available/example.com
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

и откроем его для редактирования

sudo gedit /etc/nginx/sites-available/example.com

При редактировании данного файла необходимо учитывать синтаксис конфигурации «Nginx» (см. HttpCoreModule), готовые советы по настройке связки «Nginx + PHP-FPM» (см. PHPFcgiExample) и следовать некоторым правилам/рекомендация для достижения эффективной работы сервера (см. Pitfalls).

Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «include» позволяющей указать «Nginx», что следует загрузить другой конфигурационный файл и затем продолжить чтение текущего. Создадим в папке «/etc/nginx/» каталог «common», где будут хранится общие настройки для сайта, которые затем будут подгружаться из основного конфигурационного файла «/etc/nginx/sites-available/example. com» с помощью директивы «include»

sudo mkdir /etc/nginx/common

Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных

sudo touch /etc/nginx/common/upstream

и откроем его для редактирования

sudo gedit /etc/nginx/common/upstream

и добавим в него строчки

upstream php-fpm
{
	# PHP5-FPM сервер
	server unix:/var/run/php5-fpm.sock;
}

где «php-fpm» – название для сервера выгрузки данных, для удобства.

Редактируем файл «/etc/nginx/sites-available/example.com». Добавляем строчку

include common/upstream;

для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.

Далее описываем перенаправление от HTTP к HTTPS, если, конечно, это планируется. В таком случае необходимо наличие сертификатов для HTTPS (см. https://$server_name$request_uri? permanent;
}

иначе, можно опустить эти строчки.

Начинаем описывать конфигурацию сайта

server
{

Сетевой порт для приема соединений: 80 — обычный HTTP; 443 — HTTPS (см. выше)

	# Порты
	listen	80;
	listen	443	ssl;	# использовать шифрование для этого порта

Корневая директория сайта работающего на данном сервере

	root			/var/www;

Возможные имена индексных файлов (их «Nginx» пытается открыть если он получил запрос вида «example.com/», вместо явного «example.com/index.html»)

	index			index.php index.html index.htm;

Имя сервера – обычно доменное имя Вашего сервера

	server_name		example.com www.example.com;

Настройка шифрования SSL (если оно требуется, см. выше). Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server. key -out server.crt

При этом программа запросит данные, среди них «commmon name» — следует указать доменное имя сервера. Можно использовать шаблон, если необходимо учесть домены нижнего уровня, например, «*example.com». Иначе могут возникнуть проблемы с некоторыми программами, например, «davfs2» (см man davfs2.conf).

Устаревший способ включения «HTTPS», сейчас не используется, просто для примера

	ssl on;	# шифрование включено

Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»

sudo touch /etc/nginx/common/ssl

Редактируем файл «/etc/nginx/common/ssl»

sudo gedit /etc/nginx/common/ssl

Файлы сертификатов для «HTTPS»

ssl_certificate /etc/ssl/certs/example.com_nginx.crt;		# сертификат (можно свободно распространять)
ssl_certificate_key /etc/ssl/private/example.com_nginx.key;	# приватный ключ (секретный файл - НИКОМУ НЕ ПОКАЗЫВАТЬ)

Дополнительные параметры требуемые для «HTTPS»

ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;	# указание протоколов шифрования
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_prefer_server_ciphers on;

На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл.

Продолжаем редактировать файл «/etc/nginx/sites-available/example.com». Подгружаем созданный выше конфигурационный файл с описанием настроек SSL

	# Настройка шифрования SSL
	include common/ssl;

Различные настройки. Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища)

	client_max_body_size		1000m;	# увеличение максимального объема файла для загрузки до 1ГБ

Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))

Важно учитывать порядок проверки директив «location» (см. location)

Блокировать доступ к файлам и подпапкам обычно следует посредством регулярных выражений

Корневая директория

	location "/"
		{
		index index.php index.html index.htm;	# варианты индексных файлов если имя файла в запросе не задано
		try_files	$uri $uri/	=404;	# проверить есть ли файл из запроса на диске, иначе - вернуть ошибку 404
		}

К примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так

	location "/"
	{
		index index. /drupal/(.*\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)|(\..*|Entries.*|Repository|Root|Tag|Template))((/.*)?)$"
	{
		deny all;	# запретить все для всех
		error_page 404 /drupal/index.php;	# разрешить PHP сайту самому обрабатывать ошибку
		return 404;	# вернуть код ошибки
	}

Для облачного хранилища на основе ownCloud

Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».

Создадим файл настроек для «ownCloud» и отредактируем его

sudo touch /etc/nginx/common/locations/owncloud
sudo gedit /etc/nginx/common/locations/owncloud

Добавим строчки базовых настроек

location "/owncloud/"
{
	index index.php index.html index.htm;
	try_files	$uri $uri/ =404;
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
}

И также строчки для ограничения доступа

location ~* "^/owncloud/(data|config|db_structure\. xml|README)((/.*)?)$"
{
	deny all;
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
	return 404;
}

Иначе пользователь может загрузить php-скрипт в «/owncloud/data/files/user/» и выполнить его вызвав «example.com/owncloud/data/user/files/foo.php».

Подключаем этот конфигурационный файл строчкой

include common/locations/owncloud;

в файле «/etc/nginx/sites-available/example.com».

Базовые ограничения доступа

Далее идет запрет доступа к определенным каталогам, подкаталогам и файлам сайта (или «CMS», на основе которых он построен). Опишем это в конфигурационном файле «/etc/nginx/common/locations/deny»

sudo touch /etc/nginx/common/locations/deny
sudo gedit /etc/nginx/common/locations/deny

# Ограничение доступа к разным файлам и папкам которые часто используются для хранения важной информации
location ~* "/(engine|inc|data|conf|config|bin|info|install|module|profile|theme)((/. *)?)$"
{
	deny all;
	return 404;
}

# Запрет доступа к .htaccess и .htpasswd файлам
location ~* "/\.ht"
{
	deny all;		# запретить все для всех
	return 404;		# вернуть код ошибки
}

Следует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой

sudo find /var/www/ -name .htaccess

Подключаем этот конфигурационный файл строчкой

include common/locations/deny;

в файле «/etc/nginx/sites-available/example.com».

На этом описание директорий завершено

Далее идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

В файле «php.ini» должно быть установлено «cgi.fix_pathinfo = 0;»
Также, в файле »/etc/php5/fpm/pool.d/www.conf» должно присутствовать ограничение на разширение имени
исполняемых скриптов — «security.limit_extensions = .php .php3 .php4 .php5»

Очень желательно в шаблоне указать явно где разрешено выполнение скриптов

Важно следить что-бы выполнение скриптов не происходило в папках куда их можно свободно загрузить (например, если папка доступна одновременно FTP и HTTP серверу)

Добавляем в файл «/etc/nginx/sites-available/example. (.+?\.php)(/.*)?$;
# Вместо переменной «$document_root» можно указать адрес к корневому каталогу сервера и это желательно (см. http://wiki.nginx.org/Pitfalls)
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
# См. http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;
# Указание дополнительных переменных окружения PHP
fastcgi_param SERVER_ADMIN [email protected];
fastcgi_param SERVER_SIGNATURE nginx/$nginx_version;
fastcgi_index index.php;

Сохраняем и закрываем файл, подключаем его строчкой

	include common/php-fpm;

в файле «/etc/nginx/sites-available/example.com».
Закрываем фигурные скобки директивы «location»

	}

Доступ к Nagios через Nginx

Если на сервере используется система мониторинга «Nagios», то обеспечение работы её веб-интерфейса тоже можно возложить на «Nginx», точнее на связку «Nginx+PHP-FPM/FastCGIWrap». Установим дополнительное ПО «FastCGIWrap»

sudo apt-get install fcgiwrap

это позволит открывать «*.cgi» файлы.

Открываем описанный выше файл со списком серверов выгрузки данных (upstream)

sudo gedit /etc/nginx/common/upstream

и добавим в него строчки

upstream fcgiwrap
{
	# FastCGIWrap сервер
	server unix:/var/run/fcgiwrap.socket;
}

Создаём файл с параметрами для «FastCGIWrap»

sudo touch /etc/nginx/common/fcgiwrap
sudo gedit /etc/nginx/common/fcgiwrap

где укажем

# Отключаем сжатие для быстродействия
gzip			off;

# Стандартные параметры
include			fastcgi_params;

# Доп. параметры
fastcgi_param	SCRIPT_FILENAME		$document_root$fastcgi_script_name;
fastcgi_param	PATH_TRANSLATED		$document_root$fastcgi_script_name;
fastcgi_param	SERVER_ADMIN		[email protected];
fastcgi_param	SERVER_SIGNATURE	nginx/$nginx_version;

# Направление запроса к upstream-серверу
fastcgi_pass	fcgiwrap;

Создаём файл с описанием настроек для «Nagios»

sudo touch /etc/nginx/common/locations/nagios

и откроем его для редактирования

sudo gedit /etc/nginx/common/locations/nagios

И укажем необдимые параметры. /cgi-bin/nagios3/(.+?\.cgi)$» /$1 break;

auth_basic «Authorization required to access Nagios»;
auth_basic_user_file htpasswd;

# Передаём скрипту параметры аутентификации
fastcgi_param AUTH_USER $remote_user;
fastcgi_param REMOTE_USER $remote_user;

include common/fcgiwrap;
}

Сохраняем и закрываем файл.

А в файле «/etc/nginx/sites-available/default» дописываем

	# Nagios
	include common/locations/nagios;

Закрываем фигурные скобки директивы «server» в «/etc/nginx/sites-available/default»

}

На этом правка файла «/etc/nginx/sites-available/default» завершена. Убедитесь в том, что все фигурные скобки «{ }» закрыты корректно и части файла верно вложены друг в друга («location» внутри «server» и т.п.).

Выше были описаны параметры аутентификации для доступа к «Nagios», однако сам файл с пользователем и хеш-суммой от пароля хранится в неизвестном для «Nginx» файле «/etc/nagios3/htpasswd.users». Просто перенесём эти настройки в известный для «Nginx» файл «/etc/nginx/htpasswd», например, командой выполненной от корневого пользователя «root»

cat /etc/nagios3/htpasswd. users >> /etc/nginx/htpasswd

хотя, конечно, лучше это сделать вручную.

Сохраняем все изменённые файлы.

Теперь можно перезапустить демоны

sudo service nginx restart
sudo service php5-fpm restart

FreeBSD — Настройка Nginx + PHP-FPM в chroot

Давно у меня в голове засела идея избавиться от apache2 на своих серверах. Зачем нужен этот древний тяжеленный мамонт? Ради модуля php? Ну так все хостинги давно уже обкатали режим php-fpm -это когда специфически собранный PHP работает сам по себе как сервис для компиляции php файликов. Стабильность и функциональность данного варианта работы PHP отличная! Остается статика, всякие картинки, стили, java-скрипты …. тут среди попсовых решений Nginx впереди планеты всей! Таким образом получаем простенькую систему из PHP-FPM + Nginx способную заменить Apache2 + mod_php + PHP. К тому же для большей безопасности и гибкости в настройке PHP-FPM поддерживает pools — это значит что PHP под каждый отдельный web-ресурс можно сконфигурить отдельно, к примеру сайту #1 дать 64MB RAM, а сайту #5 — 2048MB и тд, а любые превышения лимитов одним пулом не будут влиять на работу других. Для большей безопасности каждый пул можно разместить в его личном chroot-окружении, что на уровне FS изолирует все пулы друг от друга. Сладко??? Тогда в бой!
Установка PHP с флагом FPM:
Устанавливаем порт /usr/ports/lang/php5 с опцией PHP-FPM. При необходимости устанавливаем /usr/ports/lang/php5-extensions
Установка nginx:
Также из портов устанавливаем nginx, у меня он собран с такими опциями:

HTTP=on: Enable HTTP module
HTTP_ADDITION=on: Enable http_addition module
HTTP_CACHE=on: Enable http_cache module
HTTP_GZIP_STATIC=on: Enable http_gzip_static module
HTTP_GUNZIP_FILTER=on: Enable http_gunzip_filter module
HTTP_IMAGE_FILTER=on: Enable http_image_filter module
HTTP_PERL=on: Enable http_perl module
HTTP_REALIP=on: Enable http_realip module
HTTP_REWRITE=on: Enable http_rewrite module
HTTP_STATUS=on: Enable http_stub_status module
WWW=on: Enable html sample files

Не забываем про автозагрузку сервисов:
В /etc/rc. conf добавляем такие строчки для автостарта сервисов nginx и php-fpm

# <= Nginx => #
nginx_enable=»YES»
# <= PHP-FPM => #
php_fpm_enable=»YES»

Создание пользователя и окружения для chroot:
Создаем юзера, который у нас будет использоваться для виртуального web-хостинга. У меня это wwwuser. В его домешнем каталоге создаем необходимые директории для chroot php-fpm:

root@srv1:~# cd /home/wwwuser
root@srv1:/home/wwwuser# mkdir wwwchroot
root@srv1:/home/wwwuser# mkdir wwwchroot/{etc,htdocs,logs,tmp,usr}
root@srv1:/home/wwwuser# mkdir wwwchroot/usr/local
root@srv1:/home/wwwuser#

Создаем симлинки на некоторые конфиги и сокет mysql-сервера:

root@srv1:/home/wwwuser# cd wwwchroot/
root@srv1:/home/wwwuser/wwwchroot# ln -s /etc/hosts etc/hosts
root@srv1:/home/wwwuser/wwwchroot# ln -s /etc/host.conf etc/host.conf
root@srv1:/home/wwwuser/wwwchroot# ln -s /etc/resolv.conf etc/resolv.conf
root@srv1:/home/wwwuser/wwwchroot# ln -s /etc/nsswitch. conf etc/nsswitch.conf
root@srv1:/home/wwwuser/wwwchroot# ln -s /etc/localtime etc/localtime
root@srv1:/home/wwwuser/wwwchroot# ln -s /tmp/mysql.sock tmp/mysql.sock

Создаем симлинки на библиотеки:

root@srv1:/home/wwwuser/wwwchroot# ln -s /lib lib
root@srv1:/home/wwwuser/wwwchroot# ln -s /usr/local/lib usr/local/lib
root@srv1:/home/wwwuser/wwwchroot#

Настройка php-fpm:
Для удобства я «розбил» конфигурацию на основную часть [global] в конфиге /usr/local/etc/php-fpm.conf и настройки каждого веб-ресурса [pool] отдельно в директории /usr/local/etc/fpm.d/
Содержимое основного конфига:

include=etc/fpm.d/*.conf
[global]
pid = run/php-fpm.pid
events.mechanism = kqueue

Конфиги веб ресурсов нужно создавать в директории /usr/local/etc/fpm.d/. Их может быть много, поэтому удобно каждому юзеру создавать отдельный файлик. Вот пример содержимого одного из таких конфигов — /usr/local/etc/fpm. d/wwwuser_pool.conf:

[wwwuser]
prefix = /usr/home/$pool
user = wwwuser
group = wwwuser
listen = wwwchroot/tmp/php5-fpm.sock
listen.owner = www
listen.group = www
listen.mode = 0600

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 50
 
slowlog = logs/$pool.log.slow
request_slowlog_timeout = 5
request_terminate_timeout = 25
 
chroot = $prefix/wwwchroot
chdir = /htdocs
 
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f [email protected]
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 32M

После этого у вас должен нормально запуститься сервис php-fpm. Пробуем:

root@srv1:~# service php-fpm start
Starting php_fpm.
root@srv1:~#

Отлично! Поехали дальше!
Настройка nginx:
Тут я не очень разобрался, но скажем так, добился реально рабочего результата. Поэтому с удовольствием прочитаю замечания по настройке nginx в комментах. В стандартный конфиг /usr/local/etc/nginx/nginx.conf добавил секцию server для CMS Drupal версии 7:

    server {
        listen       80;
        server_name  mydomain.kiev.ua www.mydomain.kiev.ua;

        gzip on;
        gzip_static on;
        gzip_vary on;
        gzip_http_version 1.1;
        gzip_min_length 700;
        gzip_comp_level 6;
        gzip_disable «msie6»;

        access_log  /usr/home/wwwuser/logs/drupal-access.log;
        error_log   /usr/home/wwwuser/logs/drupal-error.log;

        root /usr/home/wwwuser/wwwchroot/htdocs/drupal7;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }
 
        location = /robots. /sites/.*/files/styles/ {
                try_files $uri @rewrite;
        }
 
        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
       
        location ~ /\. {
        deny  all;
        }
    }

Как видно из конфига, drupal у меня установлен в отдельной директории в htdocs, вот полный путь — /usr/home/wwwuser/wwwchroot/htdocs/drupal
После сохранения конфига можно запустить nginx:

root@srv1:~# service nginx start
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.
root@srv1:~#

Ну и после этого пробуем в браузере открыть наш сайт: http://mydomain.kiev.ua Я розпаковал в директорию drupal сам CMS — поэтому увидел приглашение к установке … все заработало с «пол-пинка». Пробовал аналогичный образом настраивать wordpress и phpBB — отлично работает, правда настройки в nginx.conf под разные движки разные, но найти их не составляет труда, зачастую на официальных сайтах разработчиков web-приложений есть готовые примеры конфига nginx.

Хай щастить!

Установка и настройка Web-сервера на Linux

Установка и настройка Web-сервера на Linux (Nginx + PHP-FPM)

Большинство людей, использующих Linux, занимаются разработкой. Ну и тут конечно же не обойтись без web-сервера. В этой статье я расскажу, как быстро установить веб-сервер, чтобы он заработал. А если у вас есть желание и время, то дальше мы попробуем его немного «донастроить».

Установка

Для начала давайте установим пакеты, которые нам потребуются, а именно:

• nginx — сам веб-сервер
• php-fpm — патч для PHP, для использования PHP как FastCGI процесса в высоконагруженных системах
• php5-mysql — работа с mysql из php
• mysql-server — БД Mysql
• phpmyadmin — web-интерфейс для работы с mysql

sudo apt-get install nginx nginx-extras
sudo apt-get install php5-cli php5-common php5-gd
sudo apt-get install php5-fpm php5-cgi php-pear php5-mcrypt
sudo apt-get install php5-mysql mysql-server phpmyadmin

Далее нам необходимо настроить Nginx и PHP-FPM. Начнем с последнего.

Настройка PHP-FPM

Прежде всего нам необходимо устранить проблему с безопасностью. Откройте файл «/etc/php5/fpm/php.ini»:

sudo nano /etc/php5/fpm/php.ini

Далее найдите строку «;cgi.fix_pathinfo = 1» и приведите её к виду:

cgi.fix_pathinfo = 0

Сохраняем файл: нажимаем F2 или Ctrl+X и отвечаем на вопрос «Сохранить изменения или нет?» буквой «Y».

Далее открываем для редактирования файл «/etc/php5/fpm/pool.d/www.conf», и в нем указываем, какие файлы будут выполняться интерпретатором PHP. Ищем параметр «security.limit_extensions» и приводим его к виду:

security.limit_extensions = .php .php3 .php4 .php5

В этом же файле правим параметр «listen»: указываем, через какой файл будут связаны «Nginx» и «PHP-FPM» (сокет). Также запрещаем кому-попало писать в сокет:

listen = /var/run/php5-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Сохраняем изменения (дальше я не буду напоминать, что файлы, которые вы правите, надо сохранять) и перезапускаем «PHP-FPM»:

sudo service php5-fpm restart

Обязательно давайте убедимся, что права доступа к сокету выставлены корректно, а именно они такие:

srw-rw---- 1 www-data www-data 0 May  2 16:36 /var/run/php5-fpm. sock

Проверить права можно командой:

ls -la /var/run/php5-fpm.sock

Настройка Nginx

Давайте попробуем настроить конфигурацию сайта example.com. Создадим конфигурационный файл для него:

sudo touch /etc/nginx/conf.d/example.com.conf

Открываем конфигурационный файл сайта example.com.conf для редактирования:

sudo nano /etc/nginx/conf.d/example.com.conf

Содержимое файла будет следующим:

server {
    listen   80;            # какой порт слушает
    root /var/www/example.com/www; # корневая директория

    access_log  /var/log/nginx/example.com.access.log;  #расположение логов данного хоста
    error_log  /var/log/nginx/example.com.error.log;

    server_name example.com example.com;

    location / {
        index index.php index.html index.htm;
    }

    location ~ \.php$ {
        fastcgi_pass   unix:/var/run/php5-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

Теперь нам надо создать файл с настройками пернаправления. (.+?\.php)(/.*)?$;
# Вместо переменной «$document_root» можно указать адрес к корневому каталогу
# сервера и это желательно (см. https://wiki.nginx.org/Pitfalls)
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
# См. https://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;
# Указание дополнительных переменных окружения PHP
fastcgi_param SERVER_ADMIN [email protected];
fastcgi_param SERVER_SIGNATURE nginx/$nginx_version;
fastcgi_index index.php;

Далее нам надо прописать наш сайт в файле hosts. откроем этот файл:

sudo nano /etc/hosts

И добавим в него строчку:

127.0.0.1       exapmle.com

Теперь осталось перезапустить сервисы:

sudo service nginx restart
sudo service php5-fpm restart

Ну вот. Все настроено и по идее работает. Теперь давайте создадим индексный файл нашего сайта и убедимся, что он доступен из браузера.

Создание директорий сайта

Как вы помните, выше мы определяли, что сайт наш должен находиться по адресу «/var/www/example.com/www». Давайте там его и расположим. Создадим файл index.php:

sudo mkdir -p /var/www/example.com/www
nano /var/www/example.com/www/index.php

Содержание файла будет примерно следующим:

<html>
   <head>
     <meta http-equiv="content-type" content="text/html; charset=utf-8" />
         <title>Это сайт example.com!</title>
   </head>
   <body>
       <h2>Hello‚ друг! Ты попал на example.com!</h2>
       <?php echo "А это уже php!"; ?>
   </body>
</html>

Ну вот! Теперь, если вы все сделали по инструкции, то по адресу https://exapmle.com у вас должна открыться эта страница.

Остались вопросы? Задвайте!

Nginx php-fpm настройка связки для отдачи PHP

Nginx является самым популярным из используемых сейчас веб-серверов. Он отличается широтой функционала (может использоваться как независимый сервер, прокси, балансер) и высокой скоростью работы.

Простейшая конфигурация, достаточная для отдачи статических сайтов — можно применять для заглушек и Landing Page:

server {

listen 80;
root /var/www/example.com:
index index.php index.html;
server name example.com
location / {
try_files $uri $uri/ =404;
}
}

Поскольку Nginx может отдавать только статику для работы ему нужен менеджер процессов — чаще всего это PHP-FPM, хотя сервер может направлять запросы в Apache, UWSGI и т.п. Можно считать, что он работает самостоятельно только в случае с PHP-FPM.

В конфигурационном файле это выглядит так:

location ~ \. php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

В качестве fastcgi_pass здесь указывается сетевой сокет 127.0.0.1:9000, также возможно указание Unix сокета — fastcgi_pass unix:/var/run/php5-fpm.sock; в случае использования fpm. Использования Unix сокета предпочтительной из соображений безопасности. Также с сокетом скорость работы будет выше.

Последние 2 директивы отвечают за передачу имени скрипта и метода запроса, их использование необходимо для корректной коммуникации fastcgi с бэкендом.

$document_root — обеспечит приведение к корневой директории
$fastcgi_script_name — заменится при запросе на путь к конкретному скрипту

Комбинация директив обеспечит правильный вызов скрипта при обращении по URI

fastcgi_param в Nginx

fastcgi_param можно указывать для всех директив конфигурационного файла
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

location /scripts {

                fastcgi_pass unix:/var/run/php5-fpm. sock;

}

location ~ \.php$ {

fastcgi_pass 127.0.0.1:9000;

}

В этом случае значения унаследуются всеми нижестоящими location-ами. Стоит помнить про один момент —  если fastcgi_param переопределить в одном из location — ни одна из одноименных вышестоящих директив учитываться не будет (для location в котором определяется fastcgi_param).

Избежать этого можно используя include, подключая с его помощью заранее созданные конфиги, текущие правила при этом не перезаписываются.

В файле fastcgi_common перечисляются директивы fastcgi_param, затем в основном конфиге файл вызывается в нужной секции.

location ~ \.php$ {

include fastcgi_common;

fastcgi_param QUERY_STRING $query_string;

fastcgi_param CONTENT_TYPE $content_type;

}

В такой файл следует помещать все директивы. (.+\.php)(/.+)$;
try_files $uri =404; #cgi.fix_pathinfo=0 in php.ini
fastcgi_pass backend;
fastcgi_index index.php;
include fastcgi_params;
}

}

В файл добавлен блок upstream backend позволяющий балансировать нагрузку на несколько бэкендов. Это позволяет сохранить приложение в работоспособном состоянии в случае отказа одного из серверов, выполняющих скрипты и отвечающих на запросы пользователя.

PHP: Конфигурация — Руководство

С FPM вы можете запускать несколько пулов процессов с разными настройками.
Это параметры, которые можно настроить для каждого пула.

слушатель. Владелец
нить

пинг. ответ
нить

Можно передать дополнительные переменные среды и обновить настройки PHP определенного пула.
Для этого вам необходимо добавить следующие параметры в файл конфигурации пула.

перезапишет их предыдущее значение.
Обратите внимание, что определение

значений,
но вместо этого добавит новое значение.

Настройки, определенные в php_admin_value и php_admin_flag
нельзя переопределить с помощью ini_set ().

Начиная с версии 5.3.3, настройки PHP также можно устанавливать на веб-сервере.

Оптимизация PHP-FPM для повышения производительности

PHP есть повсюду и, возможно, является языком, наиболее широко используемым в Интернете.

Однако он не совсем известен своими высокопроизводительными возможностями, особенно когда речь идет о системах с высокой степенью параллелизма.И это причина того, что для таких специализированных случаев использования такие языки, как Node (да, я знаю, это не язык), Go и Elixir берут верх.

Тем не менее, вы можете многое сделать для повышения производительности PHP на вашем сервере. В этой статье рассматривается сторона php-fpm , которая является естественным способом настройки на вашем сервере, если вы используете Nginx.

Если вы знаете, что такое php-fpm , смело переходите к разделу по оптимизации.

Что такое PHP-fpm?

Не многие разработчики интересуются стороной DevOps, и даже среди тех, кто интересуется, очень немногие знают, что происходит под капотом.Интересно, что когда браузер отправляет запрос на сервер, на котором запущен PHP, не PHP является точкой первого контакта; вместо этого это HTTP-сервер, основными из которых являются Apache и Nginx. Затем эти «веб-серверы» должны решить, как подключиться к PHP, и передать ему тип запроса, данные и заголовки.

Цикл запрос-ответ в случае PHP (Изображение предоставлено ProinerTech)

В современных PHP-приложениях вышеупомянутая часть «найти файл» — это index.php , которому сервер настроен для делегирования всех запросов.

Теперь, как именно веб-сервер подключается к PHP, изменилось, и эта статья взорвалась бы длиной, если бы мы вникли во все мелочи. Но, грубо говоря, в то время, когда Apache доминировал как предпочтительный веб-сервер, PHP был модулем, включенным внутри сервера.

Итак, всякий раз, когда был получен запрос, сервер запускал новый процесс, который автоматически включал PHP, и выполнял его. Этот метод назывался mod_php , сокращенно от «PHP как модуль.У этого подхода были свои ограничения, которые Nginx преодолел с помощью php-fpm .

В php-fpm ответственность за управление процессами PHP возлагается на программу PHP на сервере. Другими словами, веб-сервер (в нашем случае Nginx) не заботится о том, где находится PHP и как он загружается, если он знает, как отправлять и получать данные с него. Если вы хотите, вы можете думать о PHP в этом случае как о другом сервере, который управляет некоторыми дочерними процессами PHP для входящих запросов (таким образом, у нас есть запрос, достигающий сервера, который был получен сервером и передан на сервер — довольно сумасшедший! :-P).(. + \. php) (/.+) $;
fastcgi_pass unix: /run/php/php7.2-fpm.sock;
fastcgi_index index.php;
включить fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

Нас интересует следующая строка: fastcgi_pass unix: /run/php/php7. 2-fpm.sock; , который сообщает Nginx о необходимости взаимодействия с процессом PHP через сокет с именем php7.2-fpm.sock . Таким образом, для каждого входящего запроса Nginx записывает данные через этот файл и, получив результат, отправляет его обратно в браузер.

Еще раз хочу подчеркнуть, что это не самая полная и не самая точная картина того, что происходит, но она абсолютно точна для большинства задач DevOps.

Помимо этого, давайте резюмируем то, что мы узнали на данный момент:

• PHP не получает напрямую запросы от браузеров. Сначала их перехватывают веб-серверы, такие как Nginx.
• Веб-сервер знает, как подключиться к процессу PHP, и передает все данные запроса (буквально все вставляет) в PHP.
• Когда PHP завершает свою работу, он отправляет ответ обратно на веб-сервер, который отправляет его обратно клиенту (или браузеру, в большинстве случаев).

Или графически:

Как PHP и Nginx работают вместе (Изображение предоставлено: DataDog)

Пока отлично, но теперь возникает вопрос на миллион долларов: что именно такое PHP-FPM?

Часть «FPM» в PHP означает «Fast Process Manager», что является просто причудливым способом сказать, что PHP, запущенный на сервере, не является отдельным процессом, а скорее некоторыми порожденными процессами PHP, контроллером и убит этим менеджером процессов FPM. Именно этому диспетчеру процессов веб-сервер передает запросы.

PHP-FPM сам по себе представляет собой целую кроличью нору, так что не стесняйтесь исследовать, если хотите, но для наших целей подойдет такое подробное объяснение. 🙂

Зачем оптимизировать PHP-fpm?

Так зачем волноваться из-за всего этого танца, когда все работает нормально? Почему бы просто не оставить все как есть.

По иронии судьбы, это именно тот совет, который я даю для большинства случаев использования. Если ваша настройка работает нормально и нет особых случаев использования, используйте значения по умолчанию.Однако, если вы хотите масштабироваться не только на одной машине, то важно выжать максимум из одной, так как это может сократить счета за сервер вдвое (или даже больше!).

Еще нужно понимать, что Nginx был создан для обработки огромных рабочих нагрузок. Он способен обрабатывать тысячи соединений одновременно, но если то же самое не относится к вашей настройке PHP, вы просто потратите ресурсы, поскольку Nginx придется ждать, пока PHP завершит текущий процесс и примет во-вторых, однозначно отрицательные преимущества, которые Nginx был создан для обеспечения!

Итак, разобравшись с этим, давайте посмотрим, что именно мы изменим, пытаясь оптимизировать php-fpm .

Как оптимизировать PHP-FPM?

Расположение файла конфигурации для php-fpm может отличаться на сервере, поэтому вам нужно будет изучить его, чтобы найти его. Вы можете использовать команду find в UNIX. В моем Ubuntu путь /etc/php/7.2/fpm/php-fpm.conf . 7.2 — это, конечно же, версия PHP, которую я использую.

Вот как выглядят первые несколько строк этого файла:

 ;;;;;;;;;;;;;;;;;;;;;
; Конфигурация FPM;
;;;;;;;;;;;;;;;;;;;;;

; Все относительные пути в этом файле конфигурации относятся к установке PHP.
; префикс (/ usr).Этот префикс можно динамически изменять, используя
; Аргумент -p из командной строки.

;;;;;;;;;;;;;;;;;;
; Глобальные параметры;
;;;;;;;;;;;;;;;;;;

[Глобальный]
; Pid файл
; Примечание: префикс по умолчанию - / var
; Значение по умолчанию: нет
pid = /run/php/php7.2-fpm.pid

; Файл журнала ошибок
; Если он установлен на "syslog", журнал отправляется в syslogd вместо записи.
; в локальный файл. 
; Примечание: префикс по умолчанию - / var
; Значение по умолчанию: log / php-fpm.бревно
error_log = /var/log/php7.2-fpm.log 

Несколько вещей должны быть сразу очевидны: строка pid = /run/php/php7.2-fpm.pid сообщает нам, какой файл содержит идентификатор процесса php-fpm .

Мы также видим, что /var/log/php7.2-fpm.log — это место, где php-fpm будет хранить свои журналы.

Внутри этого файла добавьте еще три переменных, например:

 Emergency_restart_threshold 10
Emergency_restart_interval 1м
process_control_timeout 10 с 

Первые две настройки являются предупредительными и сообщают процессу php-fpm , что если десять дочерних процессов выйдут из строя в течение минуты, основной процесс php-fpm должен перезапуститься.

Это может показаться ненадежным, но PHP — это недолговечный процесс, который вызывает утечку памяти, поэтому перезапуск основного процесса в случае большого количества сбоев может решить множество проблем.

Третья опция, process_control_timeout , сообщает дочерним процессам, что они должны ждать столько времени, прежде чем выполнять сигнал, полученный от родительского процесса. Это полезно в тех случаях, когда дочерние процессы находятся в середине чего-то, например, когда родительские процессы отправляют сигнал KILL.Имея под рукой десять секунд, у них будет больше шансов завершить свои задачи и выйти из них.

Удивительно, но этот не является мясом конфигурации php-fpm ! Это потому, что для обслуживания веб-запросов php-fpm создает новый пул процессов, который будет иметь отдельную конфигурацию. В моем случае имя пула оказалось www , а файл, который я хотел отредактировать, был /etc/php/7.2/fpm/pool.d/www.conf .

Давайте посмотрим, как начинается этот файл:

; Создайте новый пул с именем «www».; переменная $ pool может использоваться в любой директиве и будет заменена на
; название пула (здесь www)
[www]

; Префикс на пул
; Это применимо только к следующим директивам:
; - 'access. log'
; - 'slowlog'
; - 'слушать' (unixsocket)
; - 'chroot'
; - чдир
; - 'php_values'
; - 'php_admin_values'
; Если не установлен, вместо него применяется глобальный префикс (или / usr).
; Примечание. Эта директива также может относиться к глобальному префиксу.
; Значение по умолчанию: нет
; префикс = / путь / к / пулам / $ пулу

; Пользователь Unix / группа процессов
; Примечание: пользователь является обязательным.Если группа не задана, группа пользователя по умолчанию
; будет использован.
пользователь = www-data
группа = www-data 

Беглый взгляд на конец приведенного выше фрагмента решает загадку, почему серверный процесс работает как www-data . Если вы столкнулись с проблемами доступа к файлам при настройке своего веб-сайта, вы, вероятно, изменили владельца или группу каталога на www-data , что позволило процессу PHP иметь возможность записывать в файлы журнала и загружать документы. , так далее.

Наконец, мы подошли к источнику проблемы — настройке диспетчера процессов (pm). Обычно значения по умолчанию выглядят примерно так:

 pm = динамический
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200 

Итак, что здесь означает « динамический »? Я думаю, что официальная документация лучше всего объясняет это (я имею в виду, что это уже должно быть частью файла, который вы редактируете, но я воспроизвел его здесь на всякий случай, если это не так):

; Выберите, как диспетчер процессов будет контролировать количество дочерних процессов.; Возможные значения:
; static - фиксированное количество (pm.max_children) дочерних процессов;
; динамический - количество дочерних процессов устанавливается динамически на основе
; следующие директивы. При таком управлении процессами будет
; всегда минимум 1 ребенок.
; pm.max_children - максимальное количество детей, которые могут
; быть живым в то же время.
; pm.start_servers - количество дочерних серверов, созданных при запуске. ; pm.min_spare_servers - минимальное количество детей в режиме ожидания
; состояние (ожидает обработки). Если число
; "простаивающих" процессов меньше этого
; число, тогда будут созданы несколько детей.
; pm.max_spare_servers - максимальное количество детей в режиме ожидания
; состояние (ожидает обработки). Если число
; простаивающих процессов больше, чем это
; число, тогда несколько детей будут убиты.; ondemand - при запуске дочерние элементы не создаются. Дети будут раздвоены, когда
; новые запросы будут подключаться. Используются следующие параметры:
; pm.max_children - максимальное количество детей, которые
; могут быть живы одновременно.
; pm.process_idle_timeout - количество секунд, по истечении которых
; неактивный процесс будет убит.
; Примечание: это значение обязательно.

Итак, мы видим, что возможны три значения:

• Статический : фиксированное количество процессов PHP будет поддерживаться, несмотря ни на что.
• Dynamic : мы можем указать минимальное и максимальное количество процессов, которые php-fpm будет поддерживать в любой момент времени.
• ondemand : Процессы создаются и уничтожаются, ну, ну, по запросу.

Итак, какое значение имеют эти настройки?

Проще говоря, если у вас есть веб-сайт с низким трафиком, «динамический» параметр большую часть времени является пустой тратой ресурсов.Предполагая, что для pm.min_spare_servers установлено значение 3, три процесса PHP будут созданы и поддерживаться, даже если на веб-сайте нет трафика. В таких случаях «ondemand» — лучший вариант, позволяющий системе решать, когда запускать новые процессы.

С другой стороны, веб-сайты, которые обрабатывают большой объем трафика или должны быстро отвечать, будут наказаны в этой настройке. Создание нового процесса PHP, включение его в пул и его мониторинг — это дополнительные накладные расходы, которых лучше избегать.

Использование pm = static фиксирует количество дочерних процессов, позволяя использовать максимальные системные ресурсы для обслуживания запросов, а не для управления PHP. Если вы все-таки пойдете по этому пути, помните, что в нем есть свои рекомендации и подводные камни. Достаточно объемная, но очень полезная статья об этом здесь.

Заключительные слова

Поскольку статьи о веб-производительности могут разжечь войны или сбить с толку людей, я считаю, что нужно сказать несколько слов, прежде чем мы закроем эту статью.Настройка производительности — это как догадки и темные искусства, так и системные знания.

Даже если вы знаете наизусть все настройки php-fpm , успех не гарантирован. Если вы понятия не имели о существовании php-fpm , то не нужно тратить время на беспокойство об этом. Просто продолжайте делать то, что вы уже делаете, и продолжайте.

В то же время, не переставайте быть наркоманом. Да, вы можете добиться еще большей производительности, перекомпилировав PHP с нуля и удалив все модули, которые вы не будете использовать, но этот подход недостаточно разумен в производственной среде. Вся идея оптимизации чего-либо заключается в том, чтобы посмотреть, отличаются ли ваши потребности от значений по умолчанию (что они редко делают!), И внести незначительные изменения по мере необходимости.

Если вы не готовы тратить время на оптимизацию своих серверов PHP, вы можете рассмотреть возможность использования надежной платформы, такой как Kinsta, которая заботится об оптимизации производительности и безопасности.

Как установить PHP-FPM с Apache в Ubuntu 18.04

Как установить PHP 7.4-FPM с Apache на Ubuntu 18.04 в Google Cloud Platform.Есть два разных варианта запуска PHP с помощью веб-сервера. Один использует CGI PHP, а другой — FPM.

FPM — это диспетчер процессов для управления FastCGI в PHP. Apache по умолчанию поставляется с mod_php и работает со всеми основными веб-серверами. С mod_php возникает небольшая проблема с производительностью, потому что он блокирует процесс.

Вы также можете настроить пулы PHP-FPM для запуска от имени другого пользователя, владеющего веб-сайтом, если вы размещаете несколько веб-сайтов на своем сервере в настройке среды chroot.

В этом руководстве вы узнаете, как настроить PHP 7.4-FPM и настроить его с помощью Apache, а также настроить пулы PHP 7.4-FPM.

Эту настройку также можно выполнить на другом VPS, выделенных или облачных виртуальных машинах. Эта установка протестирована на Google Compute Engine, но работает с любыми дистрибутивами Ubuntu или Debian Linux.

Выберите лучший хостинг для вашего бизнеса

Начало работы

Убедитесь, что на вашем сервере Ubuntu установлены последние пакеты, выполнив следующую команду.

 обновление sudo apt 
 обновление sudo apt 

Это обновит индекс пакетов и обновит установленные пакеты до последней версии.

Добавить PPA для PHP 7.4

Добавьте ondrej / php , который содержит пакет PHP 7.4 и другие необходимые расширения PHP.

 sudo apt install software-properties-common 
 sudo add-apt-repository ppa: ondrej / php 
 sudo apt update 

После добавления PPA вы можете установить PHP 7. 4.

Установите PHP 7.4 FPM

Теперь мы установим PHP 7.4-FPM и некоторые общие модули для запуска приложения PHP, такого как WordPress.

 sudo apt install php7.4-fpm php7.4-common php7.4-mysql php7.4-xml php7.4-xmlrpc php7.4-curl php7.4-gd php7.4-imagick php7.4-cli php7 .4-dev php7.4-imap php7.4-mbstring php7.4-soap php7.4-zip php7.4-bcmath -y 

Дождитесь завершения установки.

После завершения установки проверьте установку, используя следующую команду.

 служба sudo php7.Статус 4-fpm 

Вы получите результат, аналогичный приведенному ниже.

 Выход
● php7.4-fpm.service - менеджер процессов PHP 7.4 FastCGI.
    Загружено: загружено (/lib/systemd/system/php7.4-fpm.service; включено; предустановка поставщика: включено)
    Активен: активен (работает) с Thu 2020-01-09 08:36:51 UTC; 1мин 48с назад
      Документы: man: php-fpm7.4 (8)
  Основной PID: 15920 (php-fpm7.4)
    Статус: «Активные процессы: 0, бездействие: 2, Запросы: 0, медленные: 0, Трафик: 0 запросов / сек»
     Задач: 3 (лимит: 669)
    CGroup: / system. slice / php7.4-fpm.service
            ├─15920 php-fpm: главный процесс (/etc/php/7.4/fpm/php-fpm.conf)
            ├─15938 php-fpm: бассейн www
            └─15939 php-fpm: бассейн www 

Установите Apache

После того, как ваш PHP-FPM запущен, вы можете установить веб-сервер Apache.

 sudo apt установить apache2 

Настроить Apache с помощью PHP-FPM

По умолчанию Apache будет использовать mod_php , поэтому теперь вы можете настроить Apache для использования PHP-FPM.

Отключить конфигурацию виртуального хоста Apache по умолчанию.

 sudo a2dissite 000-default 

Включить модуль proxy_fcgi .

 sudo a2enmod proxy_fcgi 

Создайте новую конфигурацию виртуального хоста Apache.

 судо нано /etc/apache2/sites-available/cloudbooklet.conf 

Вставьте приведенную ниже конфигурацию в файл.

 
     Имя сервера External_IP_Address
     DocumentRoot / var / www / html

     <Каталог / var / www / html>
          Индексы опций FollowSymLinks
         AllowOverride All
         Требовать все предоставлено
     

      php $ ">
         SetHandler "прокси: unix: /var/run/php/php7.4-fpm.sock | fcgi: // localhost /"
      
 
      ErrorLog $ {APACHE_LOG_DIR} /error.log
      CustomLog $ {APACHE_LOG_DIR} /access.log вместе
 

Нажмите CTRL + X , затем Y и Введите , чтобы сохранить и закрыть файл.

Теперь вы можете включить новую конфигурацию Apache.

 sudo a2ensite cloudbooklet.conf 

Перезапустите Apache.

 sudo service apache2 перезапуск 

Тестирование PHP-FPM с Apache

Здесь мы настроили / var / www / html в качестве корневого веб-узла в конфигурации Apache. Итак, теперь вы можете перейти в этот каталог и создать файл phpinfo , чтобы проверить настройку.

 cd / var / www / html 

 sudo nano info.php 

Вставьте следующее.

 
 Нажмите  CTRL + X , затем  Y  и  Введите , чтобы сохранить и закрыть файл.
 Теперь перейдите в браузер и укажите IP-адрес вашего сервера или доменное имя, а затем введите  info.php . Ваш адрес будет выглядеть так:  http: //IP_Address/info.php 
 Вы увидите информационную страницу PHP и подтвердите, что PHP-FPM используется с Apache.
 Конфигурация PHP-FPM 
 PHP INI:  /etc/php/7.4/fpm/php.ini 
 Конфигурация пула:  /etc/php/7.4/fpm/pool.d/www.conf 
 Создать новый пул PHP-FPM с другим пользователем 
 По умолчанию Nginx и Apache работают как пользователь  www-data .PHP-FPM  www.conf  также настроен для работы как пользователь  www-data . Если у вас несколько веб-сайтов и вы хотите изолировать их с помощью chrooted-настройки, запускайте их с собственным пользователем. Вы можете создать несколько пулов PHP-FPM с разными пользователями.
 Создайте новую конфигурацию пула PHP-FPM.
 судо нано /etc/php/7. 4/fpm/pool.d/user1.conf 
 Вставьте следующее.
 [пользователь1]
пользователь = пользователь1
группа = группа1

слушайте = /run/php/php7.4-fpm-user1.sock

Слушать.owner = www-data
listen.group = www-data

pm = динамический
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3 
 Теперь создайте новый файл конфигурации Apache vhost и установите обработчик для нового пула, который вы создали.
 судо нано /etc/apache2/sites-available/site1.conf 
 
     ServerName domain.com
     DocumentRoot / var / www / html / site1

     
          Индексы опций FollowSymLinks
         AllowOverride All
         Требовать все предоставлено
     

     
         SetHandler "прокси: unix: /var/run/php/php7.4-fpm-user1.sock | fcgi: // localhost /"
      
 
      ErrorLog $ {APACHE_LOG_DIR} /error.log
      CustomLog $ {APACHE_LOG_DIR} /access. log вместе
 
 Включить новый сайт.
 sudo a2ensite site1.conf 
 Убедитесь, что новый корневой веб-сайт принадлежит пользователю, указанному в конфигурации пула и входящему в указанную группу.
 Службы перезапуска 
 После завершения настройки необходимо перезапустить PHP-FPM и Apache, чтобы изменения вступили в силу.
 судо php-fpm7.4 -t
sudo service php7.4-fpm перезапуск 
 sudo service apache2 перезапуск 
 Вы можете создать столько пулов, сколько захотите, используя вышеупомянутую настройку с PHP-FPM. Это гибкость, доступная с PHP-FPM.
 Станьте системным администратором  Linux  и обслуживайте виртуальные серверы в многопользовательской среде.
 Заключение 
 Теперь вы узнали, как установить PHP 7.4-FPM с Apache и настроить Apache. Вы также научились настраивать пулы PHP-FPM для нескольких пользователей.
 NGINX PHP Установка FPM для веб-сайтов с высокой посещаемостью 
 В эту эпоху информационных технологий люди увлечены Интернетом и связываются друг с другом через беспроводные сети. Люди предпочитают онлайн во всем, включая покупки, чтение и игры. Следовательно, чтобы преуспеть в современном бизнесе, вам нужен профессиональный веб-сайт, который позволит охватить больше потребителей.
 PHP - самый популярный и предпочтительный язык для создания веб-сайтов. Это открытый, платформенно-независимый и легкий язык с открытым исходным кодом.Вот преимущества разработки веб-сайта на PHP:
 Легко разрабатывать и управлять
 Низкие затраты на разработку и обслуживание
 Обеспечивает высокую производительность и надежность
 Он также обеспечивает гибкость базы данных
 С PHP 7 объектно-ориентированное программирование становится простым и продвинутым
 Скорость и производительность веб-сайта играют важную роль в успехе любого бизнеса. Вот где появился NGINX. Для выполнения файлов PHP нам понадобится веб-сервер и исполняемые файлы PHP.Apache - это веб-сервер по умолчанию, используемый для запуска файлов PHP. Когда была огромная тяга к инновациям с использованием новых технологий, предпочтительной платформой была Apache. Однако, когда дело доходит до скорости, он не может установить предпочтительный тест. Поскольку он всегда порождает дочерний процесс каждый раз, когда приходит новый запрос. Таким образом, когда веб-сайт получает много запросов, возникают проблемы с ОЗУ. Это связано с тем, что каждый процесс занимает часть оперативной памяти для обработки запросов. NGINX - это решение проблемы ограничений Apache.
 Что такое NGINX? 
 NGINX - еще один популярный веб-сервер с открытым исходным кодом, разработанный Игорем Сысоевым. Он хорошо известен благодаря высокопроизводительному балансировщику нагрузки и специально разработан для ускорения большой службы на основе Apache.
 Источник изображения: slideshare.com
 NGINX PHP-FPM (PHP - FastCGI Process Manager) - лучший вариант для повышения производительности. PHP-FPM - это альтернативный FastCGI для PHP, предназначенный для обработки высоких нагрузок. NGINX использует архитектуру, управляемую событиями, и занимает около 10 МБ ОЗУ при обработке большого количества запросов.PHP-FPM улучшен с точки зрения скорости. Это намного лучше, чем модуль mod_php - модуль по умолчанию на HTTP-сервере Apache. PHP-FPM - это независимый процесс, который не требует загрузки веб-сервером, тогда как mod-php блокирует процессы и влияет на производительность веб-сайта. Кроме того, PHP-FPM содержит ряд эффективных функций, в том числе:
 Адаптивный порождение процесса
 Поддержка "медленного журнала"
 Stdout & stderr логирование
 Базовая статистика
 Поддержка ускоренной загрузки
 Аварийный перезапуск при случайном разрушении кеша опкодов
… и многое другое.
 Помимо этих преимуществ NGINX PHP-FPM, они обмениваются данными через TCP; следовательно, оба обеспечивают малый объем памяти.
 Установка NGINX PHP-FPM в Ubuntu - Linux 
 Шаг 1. Установка NGINX 
 Поскольку NGINX является репозиторием Ubuntu по умолчанию, вы можете установить его с пакетом  apt , используя следующие команды: [источник команды : websiteforstudents. com ]
 После установки вы можете использовать эти команды для остановки, запуска и включения NGINX, а также для проверки состояния службы NGINX:
 Вот пример вывода статуса сервера:
 Источник: cyberciti
 Шаг 2: Установка PHP-FPM и связанных модулей 
 У нас есть несколько модулей PHP, которые выполняют различные функции.Давайте включим некоторые важные из них, которые всегда необходимы при создании веб-сайтов на PHP. Приведенная ниже команда устанавливает PHP-FPM и важные модули:
 Приведенная выше команда позволяет PHP работать с популярными сайтами и приложениями на основе PHP.
 Шаг 3. Настройте NGINX с PHP 
 После установки NGINX и PHP пора настроить NGINX и PHP.
 Расположение конфигурации PHP NGINX по умолчанию:
 Здесь x изменяется от 0 до 1 в зависимости от версии PHP.
 Используйте следующую команду, чтобы открыть файл конфигурации NGINX PHP
 Теперь вы можете редактировать файл в зависимости от вашей среды. Вот некоторые важные строки, на которых стоит сосредоточиться:
 Затем вам нужно открыть файл конфигурации сайта NGINX - его расположение по умолчанию
 Используйте следующую команду, чтобы открыть файл:
 После открытия, чтобы включить поддержку NGINX PHP, раскомментируйте строки, выделенные в команде ниже:
 Далее, перезапустите службы NGINX и PHP-FPM
 Шаг 4. Тестирование конфигурации PHP-FPM 
 На этом этапе вы должны проверить, готова ли установка NGINX PHP-FPM или нет - создайте пустой файл с помощью команды:
 Затем введите строку, указанную ниже, и сохраните изменения:
 Теперь откройте браузер и найдите имя сервера или IP-адрес с именем файла, как показано ниже:
 Источник: сайт для студентов
 Если вы обнаружите результат, похожий на показанный выше, значит, вы успешно настроили NGINX PHP FPM на своем сервере Ubuntu или Linux.
 Преимущества NGINX по сравнению с Apache 
 NGINX поддерживает обратный прокси, используя эту функцию; мы можем уменьшить количество обращений к нашим приложениям, включив балансировку нагрузки.
  NGINX Plus как обратный прокси для PHP-бэкэнда 
 Источник: nginx.com
 Наряду с балансировкой нагрузки NGINX Plus предлагает более сложную персистентность сеанса
 NGINX работает лучше, чем Apache2, при высоком трафике и при обслуживании статических файлов
 Поскольку NGINX находится между клиентами (например,грамм. браузеры) и приложение, оно может действовать как кеш. Это приводит к резкому сокращению времени ответа с точки зрения клиента
 Технология микрокэширования NGINX увеличивает производительность
 NGINX - самый известный веб-сервер, отвечающий за размещение крупнейших сайтов с наибольшим трафиком в сети. Теперь, когда вы установили свой веб-сервер NGINX, у вас есть несколько вариантов того, какой контент будет обслуживать, а также технологии, необходимые для создания более удобного интерфейса.
 PHP-FPM - HTTPD - Apache Software Foundation 
 С выпуском apache httpd 2. 4 для ничего не подозревающих людей мы получили некоторые очень полезные функции, касающиеся apache и php: возможность запускать PHP в качестве сервера процессов fastCGI и обращаться к этому серверу fastCGI  непосредственно из apache  через выделенный прокси-модуль (mod_proxy_fcgi.)
 Начиная с версии 5.3.3 в начале 2010 года, PHP объединил диспетчер процессов php-fpm fastCGI в свою кодовую базу, и теперь (начиная с версии 5.4.1) довольно стабильно.
 php-fpm ранее был найден на http://php-fpm.org
 Это означает, что теперь мы можем запускать безопасный, быстрый и надежный PHP-код , используя только стандартные версии apache httpd и php.net ; Больше не нужно возиться с  suphp  или  suexec  - или, действительно, с  mod_php .
 php-fpm 
 Предварительные требования:
 установка пакетов программного обеспечения
 редактирование файлов конфигурации
 управление сервисными демонами.
 Начиная с версии 5.3.3, PHP теперь включает диспетчер процессов fastCGI (php-fpm) в исходный код акции.
 Ваш дистрибутив или ОС будут либо включать его в стандартный пакет PHP, либо делать его доступным как дополнительный пакет; вы можете собрать его из исходного кода, добавив  --enable-fpm  в ваши параметры ./configure.
 Это дает нам новый двоичный файл с именем  php-fpm , а файл конфигурации по умолчанию с именем  php-fpm.conf  установлен в  / etc .
 Значения по умолчанию в этом файле должны подойти для начала работы, но имейте в виду, что ваш дистрибутив мог его изменить или изменить его местоположение.
 Внутри этого файла конфигурации вы можете создать произвольное количество «пулов» fastcgi, которые определяются IP и портом, который они прослушивают, как и виртуальные хосты apache.
 Самая важная настройка в каждом пуле - сокет TCP (IP и порт) или сокет домена unix (UDS), который php-fpm будет прослушивать для получения запросов fastCGI; это настраивается с помощью опции  слушать .
 Пул по умолчанию,  [www] , настроен как  listen 127.0.0.1:9000 : он будет отвечать только на запросы на локальном петлевом сетевом интерфейсе (localhost), на TCP-порту 9000.
 Также из интерес представляют параметры  для каждого пула, , , пользовательский  и , группа , которые позволяют запускать этот конкретный пул fpm под заданными uid и gid; до свидания, suphp!
 Обратите особое внимание на настройки slowlog (директивы request_slowlog_timeout и slowlog), то есть с помощью этого журнала и разумного времени ожидания вы можете легко увидеть, какие вызовы php из вашего приложения занимают больше времени, чем ожидалось, и сразу же начать их отладку.
 Давайте просто воспользуемся заводскими настройками по умолчанию и запустим демон php-fpm; если ваш дистрибутив использует предоставленный сценарий инициализации, запустите 
  /etc/init. d/php-fpm start  
 Или, если нет, запустите его вручную с помощью 
  php-fpm -y /path/to/php-fpm.conf -c /path/to/custom/php.ini  
 Если вы не предоставите php-fpm собственный файл  php.ini , будет использоваться глобальный файл   php.ini. Помните об этом, если вы хотите включить больше или меньше расширений, чем используют двоичные файлы CLI или CGI, или если вам нужно изменить некоторые другие значения там.
 Вы можете включить  значений php.ini  для каждого пула точно так же, как вы определяли их в apache ранее для mod_php, используя  php_ [admin _] (flag | value) .
 См. Официальную документацию PHP  для fpm  для всех возможных вариантов конфигурации.
 Я также изменил параметр php-fpm.conf  logging , чтобы я мог легко видеть, что именно регистрируется php-fpm: 
  error_log /var/log/php-fpm. log  
 Если вы этого не сделаете установите файл журнала php-fpm, ошибки будут регистрироваться, как определено в  php.ini .
 Примечание: вы можете заставить запущенный php-fpm перезагрузить свою конфигурацию, отправив ему сигнал SIGUSR2 .; SIGUSR1 будет циклически повторять файлы журнала (идеально для сценария logrotate!). Небольшое экспериментирование имеет большое значение.
 Вот и все, о чем мы позаботились о php-fpm; если при запуске не было ошибок, он должен быть готов к подключению.
 apache httpd 2.4 
 предварительные требования:
 редактирование httpd.conf
 понимание контекста vhost
 понимание сопоставления пространства имен URL-адрес файловой системы
 управление демоном apache httpd
 В этом выпуске apache httpd были представлены два примечательные особенности: новый модуль прокси специально для fastCGI (mod_proxy_fcgi) и переход на событие   MPM в качестве диспетчера процессов apache по умолчанию.
 Как и в случае с рабочим MPM предыдущей версии, многопоточная модель этого MPM вызывает проблемы, когда mod_php используется с  небезопасными для потоков  сторонними расширениями PHP.
 Это было проклятием для пользователей mod_php с тех пор, как был выпущен apache 2.2, практически вынуждая их собирать решения fastcgi или использовать гораздо более медленный и требовательный к памяти prefork MPM.
 Чтобы творить чудеса с менеджером процессов PHP fastCGI, мы будем использовать новый модуль,  mod_proxy_fcgi , который предназначен специально для связи с (возможно внешними) серверами fastCGI.
 Убедитесь, что вы включили модуль proxy_fcgi в свой httpd.conf, чтобы мы могли использовать его возможности; поскольку для этого требуется базовый прокси-модуль, убедитесь, что оба загружены (без комментариев):
  LoadModule proxy_module modules / mod_proxy.so 
  LoadModule proxy_fcgi_module modules / mod_proxy_fcgi. so 
 Теперь есть разные способы пересылки запросов для файлов .php с  по  этот модуль, от всего (с использованием [ProxyPass]) до очень конкретных или перезаписанных файлов или шаблонов (с использованием mod_rewrite с флагом [P]).Знаки  (каретка) и  $  (доллар) используются для  привязки  как к абсолютному началу, так и к концу URL-адреса, чтобы гарантировать, что никакие символы из запроса не выходят за рамки нашего сопоставления с шаблоном.
 Вложенные круглые скобки позволяют нам ссылаться на весь URI запроса (за вычетом ведущей косой черты) как  $ 1 , при этом оставляя конечную информацию о пути необязательной.
  fcgi: //127.0.0.1: 9000 
 переслать через mod_proxy_fcgi, используя протокол fastCGI, на порт, который слушает наш демон php-fpm.
 Определяет, какой пул  fastcgi  будет обслуживать запросы, проксируемые этим правилом. 
  / path / to / your / documentroot / 
 ВАЖНО! Это должно  точно  совпадать с  реальным расположением  файловой системы ваших файлов php, потому что именно там демон php-fpm будет их искать.
 php-fpm просто интерпретирует переданные ему файлы php; это не веб-сервер, и он не понимает пространство имен ваших веб-серверов, макет виртуального хоста или псевдонимы.
 ВАЖНО! Прочтите приведенное выше снова 
  $ 1 
 расширяется на весь URI запроса из исходного запроса, за вычетом ведущей косой черты (потому что мы уже добавили это выше.)
  DirectoryIndex /index.php index.php 
 запрос для / должен быть сопоставлен с ресурсом на бэкэнде fcgi. Неспособность решить эту проблему может вызвать пустой ответ, обычно известный как WSOD (Белый экран смерти), особенно если проксируется только URI запроса, содержащий расширение php, как в этом примере. Цепочка обработки сначала отобразит запрос для / на /index. php или любой другой файл index.php относительно текущего uri запроса, а затем будет правильно проксировать серверную часть PHP-FPM./(.*\.php(/.*)?)$ unix: /path/to/socket.sock | fcgi: // localhost / path / to / your / documentroot / 
  unix: / path / to /socket.sock 
 путь к вашему сокету fpm
  Обратите внимание, что при таком подходе URI захваченного запроса ($ 1) не передается после пути 
 Прокси через обработчик 
 При таком подходе вы можете проверить наличие наличие ресурса до проксирования на бэкэнд php-fpm.
  # Определение воркера улучшит производительность 
  # И в этом случае повторно используйте воркера (в зависимости от поддержки со стороны приложения fcgi) 
  # Если у вас достаточно простаивающих воркеров, это только улучшит производительность незначительно 
   
   
   php $ "> 
 {{}}
 {{# Выберите один из следующих подходов}}
 {{# Использовать стандартный сокет TCP}}
 { {#SetHandler "proxy: fcgi: // localhost /: 9000"}}
 {{# Если ваша версия httpd - 2.4.9 или новее (или имеет функцию обратного переноса), вы можете использовать сокет домена unix }}
 {{#SetHandler "proxy: unix: /path/to/app.sock | fcgi: // localhost /"}}
 {{}}
   
 Объединение FilesMatch и If может быть достигнуто как таковое:
   
 Для нетерпеливых 
 Очень простой пример 
 Если вас интересует проверка концепции и вы хотите оставить настройку на потом, вы можете использовать следующий рецепт.Он вызовет стандартную информационную страницу php, на которой перечислены все скомпилированные и загруженные расширения, а также все параметры конфигурации времени выполнения и информация о скрипте. / (.* \. php) $ fcgi: //127.0.0.1: 9000 / var / www / $ 1 
 Опять же, предполагая, что  / var / www  - это  DocumentRoot  рассматриваемого виртуального хоста.
 Перезагрузите apache с  apachectl graceful , и теперь вы можете вызвать страницу phpinfo, используя  http://example.com/yourscript.php 
 Performance and Pitfalls 
 mod_proxy_fcgi теперь поддерживает сокеты домена unix, начиная с версии 2.4.9 ( Поддержка сокетов домена Unix для mod_proxy_fcgi)
 Легко перегрузить доступные сокеты вашей системы, пропустить ulimit и т. Д.Несколько советов, как этого избежать:
 Использование слишком большого количества сокетов приведет к тому, что apache выдаст ошибку  (99) Невозможно назначить запрошенный адрес: . Это означает, что ваша операционная система не позволяет создавать новые сокеты.
 В linux вы можете использовать / proc / sys / net / ipv4 / tcp_tw_reuse, чтобы не создавать столько сокетов, но есть предупреждения, связанные с использованием этого за NAT.
 Обязательно измените ulimit и разрешите достаточно открытых файлов и процессов как для пользователя apache, так и для пользователя php-fpm.
  ulimit -n  и  ulimit -u  (nofile и nproc)
 Если php-fpm не имеет достаточно большого nproc, он выйдет ( код 255 , без дополнительной информации с php 5.3) в цикле без дополнительных сообщений.
 Если php-fpm не имеет достаточно большого файла nofile, вы, вероятно, не сможете вести журнал для каждого ребенка, как показано выше. Это будет отражено в общем журнале ошибок.
 Если apache и php-fpm запускаются от имени одного и того же пользователя (не обязательно или рекомендуется) и nproc слишком мал, apache не запускается со следующим сообщением  (11) Ресурс временно недоступен: AH02162: setuid: невозможно изменить на uid : 600 
 Предупреждение: когда вы ProxyPass отправляете запрос другому серверу (в данном случае демону php-fpm), ограничения аутентификации и другие конфигурации помещаются в блок каталога или. htaccess, можно обойти.
 Предостережения 
 Может возникнуть соблазн указать на то, что жадная директива  ProxyPassMatch  может разрешить обслуживание некоторого вредоносного содержимого, загруженного HTTP-клиентом.
 Это ни в коем случае не исчерпывающий документ по безопасности, но вместо этого он укажет на возможный вектор внедрения, который может быть сгенерирован из директив в этом документе.
 Возьмем, например:
  /uploads/malicious.jpg/lalalaalala.php 
 Приведет php-fpm к обработке этого файла (/ uploads / malware.jpg) и без определенной проверки работоспособности может привести к взлому сервера.
 Это, конечно, не рекомендуется. Содержимое, загруженное с использованием php, должно быть безопасно сохранено за пределами  DocumentRoot , а pathinfo должен быть тщательно изучен.
 Кроме того, php-fpm должен проверять, разрешен ли вызываемый скрипт.
 Если такие ограничения не могут быть легко реализованы, то проверки могут быть выполнены до проксирования с помощью  RewriteCond  или  FallbackResource , чтобы гарантировать, что URI не изменяется клиентом HTTP.
 Эксперименты с тайм-аутом 
 Для долго выполняющихся скриптов может помочь установка большого тайм-аута. Этот подход устанавливает значение тайм-аута на 300 секунд и позволяет вам выбирать, какие запросы проксируются:
  
   Время ожидания ProxySet = 300



   SetHandler "прокси: fcgi: // localhost"
  
 Настройка индивидуальных пулов для PHP-FPM и NGINX 
 Php fpm - это новый способ настроить php для работы с вашим веб-сервером.Php-fpm - это менеджер процессов fastcgi для php, который полностью отделен от веб-сервера. Веб-сервер связывается с fpm через сокет и передает имя сценария для выполнения. Таким образом, fpm может работать с любым веб-сервером, совместимым с fastcgi.
 Недавно я переехал со своего старого виртуального хостинга на линод. Linode предоставляет хостинг linux vps по экономичным ценам. Однако серверы полностью неуправляемы - это просто необработанные машины Linux, у которых есть доступ к оболочке. Итак, через оболочку вы должны настроить все, включая веб-сервер, php и веб-файлы.
 Итак, на этот раз я решил использовать комбинацию nginx и php-fpm. Мне нужно было настроить несколько сайтов на этом новом веб-сервере. Nginx решает эти проблемы с помощью отдельных серверных блоков (также известных как vhost в apache). Однако требовалось другое. Php на каждом сайте должен запускаться с собственным пользователем, а не с общим пользователем nginx с именем www-data.
 Запуск каждого сайта с собственным uid / gid более безопасен и с ним легче работать. Если все сайты работали с одним и тем же пользователем, то php на одном сайте мог читать / записывать файлы других пользователей.Это проблема безопасности. Кроме того, наличие отдельных пользователей дает такие преимущества, как отдельные crontab, возможность идентифицировать процессы от каждого пользователя и т. Д.
 Отдельные бассейны 
 Php-fpm создает и управляет пулом процессов php, также называемых рабочими, которые получают и серверные запросы на выполнение файлов php из веб-каталога. Теперь fpm может запускать несколько отдельных пулов, каждый со своим собственным uid / gid. На самом деле это очень просто настроить.
 В ubuntu каталог, содержащий файлы конфигурации пула, - это  / etc / php5 / fpm / pool.д / 
 Уже существует файл с именем  www.conf , который можно скопировать для создания дополнительных файлов конфигурации пула. Каждый файл должен заканчиваться на .conf, чтобы php fpm распознал его как файл конфигурации пула.
 Файл очень длинный, но начинается примерно так.
 ; Создайте новый пул с именем «www».
; переменную $ pool можно использовать в любой директиве, и она будет заменена на
; название пула (здесь www)
[www]

; Префикс на пул
; Это применимо только к следующим директивам:
; - 'slowlog'
; - 'слушать' (unixsocket)
; - 'chroot'
; - чдир
; - 'php_values'
; - 'php_admin_values'
; Если не установлен, вместо него применяется глобальный префикс (или / usr). ; Примечание. Эта директива также может относиться к глобальному префиксу.
; Значение по умолчанию: нет
; префикс = / путь / к / пулам / $ пулу

; Пользователь Unix / группа процессов
; Примечание: пользователь является обязательным. Если группа не задана, группа пользователя по умолчанию
; будет использован.
пользователь = просвещенный
группа = просвещенная

; Адрес для приема запросов FastCGI.
; Допустимые синтаксисы:
; 'ip.add.re.ss: port' - для прослушивания через TCP-сокет определенного адреса на
; конкретный порт;
; 'порт' - для прослушивания через TCP-сокет всех адресов на
; конкретный порт;
; '/ path / to / unix / socket' - слушать сокет unix.; Примечание: это значение обязательно.
слушайте = /var/run/php5-fpm.sock

; Установить невыполнение ожидания listen (2).
; Значение по умолчанию: 128 (-1 в FreeBSD и OpenBSD)
; listen.backlog = 128
  
 Итак, создайте копию этого файла и назовите ее как-нибудь вроде сайта, который будет использовать этот пул. Важные поля для редактирования:
 Название пула. Он входит в топ  [www] . Переименуйте его в  [mysite] .
 Затем измените поле пользователя и группы и введите имя пользователя и группу, с которой будет запускаться.
  пользователь = mysite_user
группа = mysite_user
  
 Измените имя файла сокета. У каждого пула должен быть свой отдельный сокет. И конкретный сайт должен использовать этот конкретный файл сокета для подключения к fpm.
  listen = /var/run/php5-fpm-mysite.sock 
 Теперь перезапустите php-fpm
  $ sudo service php5-fpm перезапуск 
 Теперь проверьте процессы в  htop . Вы должны увидеть, что новый пул работает с отдельным именем пользователя.(. + \. php) (/.+) $;
# ПРИМЕЧАНИЕ: у вас должно быть "cgi.fix_pathinfo = 0;" в php.ini
# Только с php5-cgi:
 # fastcgi_pass 127.0.0.1:9000;
 # С php5-fpm:
 fastcgi_pass unix: /var/run/php5-fpm.sock;
 fastcgi_index index. php;
 включить fastcgi_params;
fastcgi_param PATH_INFO $ uri;
 }
 
 Поместите путь дескриптора сокета в строку fastcgi_pass.
  fastcgi_pass unix: /var/run/php5-fpm-mysite.sock; 
 Вот и все. Nginx теперь будет использовать этот сокет и, следовательно, его пул для mysite.
 Установка Nginx с PHP-FPM в Ubuntu 20.04 
 Это руководство было создано, чтобы помочь пользователям, работающим с сервером Ubuntu 20.04, установить веб-сервер Nginx и настроить PHP-FPM (FastCGI Process Manager). Nginx — это бесплатный высокопроизводительный веб-сервер. Nginx разработан для обеспечения скорости и масштабируемости с возможностями обратного прокси-сервера и балансировки нагрузки на ряд внутренних серверов с протоколами HTTP, TCP и UDP. Этот веб-сайт работает на WordPress и Nginx и имеет действительно хорошую производительность.Nginx имеет небольшой объем памяти по сравнению с Apache, обрабатывая такое же количество одновременных подключений.
 Особенности Nginx 
  Кэш содержимого  — Кэширование статического и динамического содержимого
  Балансировка нагрузки  — Балансировка нагрузки HTTP, TCP и UDP с маршрутизацией запросов уровня 7 с использованием URI, файлов cookie, аргументов и т. Д.
  Обратный прокси  несколько протоколов: HTTP, gRPC, memcached, PHP ‑ FPM, SCGI, uwsgi
 Одновременная обработка сотен тысяч клиентов
 Потоковое HTTP-видео: FLV, HDS, HLS, MP4
 HTTP / 2 шлюз с поддержкой HTTP / 2 server push
 Dual-stack RSA / ECC SSL / TLS offload
  Плагины мониторинга : Плагины AppDynamics, Datadog, Dynatrace
 Шаг 1. Обновите Ubuntu 
 Перед тем, как начать, вы должны иметь работающий сервер Ubuntu, который был обновлен до последних доступных пакетов.
  sudo apt update
sudo apt upgrade  
 Шаг 2: Установите Nginx в Ubuntu 20.04 Linux 
 После обновления системы перейдите к установке пакета Nginx в Ubuntu 20.04 Linux:
  sudo apt install nginx  
 Служба должна запускаться автоматически после установка.
  $ systemctl status nginx
● nginx.service - высокопроизводительный веб-сервер и обратный прокси-сервер.
     Загружен: загружен (/ lib / systemd / system / nginx.служба; включено; предустановка поставщика: включена)
     Активен: активен (работает) с Сб 2020-05-09 19:38:43 UTC; 39с назад
       Документы: человек: nginx (8)
   Основной PID: 6449 (nginx)
      Задач: 2 (лимит: 2344)
     Память: 3,8 МБ
     CGroup: /system.slice/nginx.service
             ├─6449 nginx: главный процесс / usr / sbin / nginx -g демон включен; master_process on;
             └─6451 nginx: рабочий процесс

09 мая, 19:38:43 ubuntu20 systemd [1]: Запуск высокопроизводительного веб-сервера и обратного прокси-сервера ...
09 мая, 19:38:43 ubuntu20 systemd [1]: запущен Высокопроизводительный веб-сервер и обратный прокси-сервер. 
 Обратите внимание, что вы не можете запускать Apache и Nginx на одном порту. Вам нужно будет отключить веб-сервер Apache или изменить порт одного из них на не стандартный порт http.
  sudo systemctl disable --now apache2  
 Брандмауэр UFW можно настроить так, чтобы разрешить порт 80:
  sudo ufw allow proto tcp с любого на любой порт 80,443  
 Шаг 3. Установите PHP-FPM на Ubuntu 20.04. 
 Если вы планируете использовать PHP с Nginx, подумайте об установке пакета PHP-FPM.
  sudo apt update
sudo apt install php php-cli php-fpm php-json php-pdo php-mysql php-zip php-gd php-mbstring php-curl php-xml php-pear php-bcmath  
 PHP-FPM имеет службу, которая должен работать.
  $ systemctl status php7.4-fpm.service
● php7.4-fpm.service - менеджер процессов PHP 7.4 FastCGI.
     Загружено: загружено (/lib/systemd/system/php7.4-fpm.service; включено; предустановка поставщика: включено)
     Активен: активен (работает) с Сб 2020-05-09 19:50:53 UTC; 2мин 26с назад
       Документы: man: php-fpm7.4 (8)
   Основной PID: 22141 (php-fpm7.4)
     Статус: «Активные процессы: 0, бездействие: 2, Запросы: 0, медленные: 0, Трафик: 0 запросов / сек»
      Задач: 3 (лимит: 2344)
     Память: 9,3 МБ
     CGroup: /system.slice/php7.4-fpm.service
             ├─22141 php-fpm: главный процесс (/etc/php/7.4/fpm/php-fpm.conf)
             ├─22142 php-fpm: бассейн www
             └─22143 php-fpm: бассейн www

09 мая, 19:50:53 ubuntu20 systemd [1]: Запуск диспетчера процессов FastCGI PHP 7.4 ...
09 мая, 19:50:53 ubuntu20 systemd [1]: Запущен PHP 7.4 FastCGI Process Manager.
  
 PID и файл сокета находятся в каталоге:
  $ ls / run / php /
php-fpm.sock php7.4-fpm.pid php7.4-fpm.sock  
 Шаг 4: Настройте PHP-FPM с Nginx в Ubuntu 
 Отредактируйте файл конфигурации Nginx приложения и установите раздел  fastcgi_pass  для загрузки через Разъем FPM. См. Ниже фрагмент.
  $ cat /etc/nginx/php_fastcgi.conf
# 404
try_files $ fastcgi_script_name = 404;

# default fastcgi_params
включить fastcgi_params;

# настройки fastcgi
fastcgi_pass unix: / запустить / php / php7.4-футовый носок;
fastcgi_index index.php;
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32 КБ;
fastcgi_hide_header X-Powered-By;
fastcgi_hide_header X-CF-Powered-By;
  
 Перезагрузите Nginx и откройте свое приложение в Интернете, чтобы убедиться, что оно работает должным образом.
No related posts.