Php fpm что это

PHP-FPM — A simple and robust FastCGI Process Manager for PHP

PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites.

These features include:

• Adaptive process spawning (NEW!)
• Basic statistics (ala Apache’s mod_status) (NEW!)
• Advanced process management with graceful stop/start
• Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode)
• Stdout & stderr logging
• Emergency restart in case of accidental opcode cache destruction
• Accelerated upload support
• Support for a «slowlog»
• Enhancements to FastCGI, such as fastcgi_finish_request() — a special function to finish request & flush all data while continuing to do something time-consuming (video converting, stats processing, etc.)

It was not designed with virtual hosting in mind (large amounts of pools) however it can be adapted for any usage model.

Nov 29, 2011
It’s official. PHP-FPM is no longer marked as «experimental» as of PHP 5.4.0RC2.

Jan 11, 2011
PHP-FPM patch released for PHP 5.2.17. Download.

Dec 16, 2010
PHP-FPM patch released for PHP 5.2.16. Download.

Dec 09, 2010
PHP-FPM patch released for PHP 5.2.15. Download.

Jul 22, 2010
PHP 5.3.3 is released and now bundles PHP-FPM, with all of the new improvements — adaptive process spawning, the new INI file format and include support, basic metrics for reporting, and more. If your code is PHP 5.3 compliant, it is highly recommended that you upgrade to take advantage of the built-in PHP-FPM support now (not to mention mysqlnd and all the other new features.)

PHP-FPM patch released for PHP 5.2.14. Download.

May 26, 2010
Antony Dovgal announced that PHP-FPM is now being packaged in PHP core’s trunk. Read here. Official instructions for downloading will be up shortly.

May 13, 2010
PHP-FPM patch released for PHP 5.2.13. Download, Changelog.

Mar 17, 2010
Antony Dovgal says PHP core’s PHP-FPM will not be released in PHP 5.3.3, but looks like PHP 5.4. Read here. Update: it made it in to 5.3.3!

Dec 04, 2009
Antony Dovgal announces PHP-FPM has been put into a SVN branch in PHP core. This is an exciting development. It will be a while before it hits production status, but this is a great move for the future.

Nov 23, 2009
I’m working on restructuring the wiki and such. Please bear with me.

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

Интерпретатор языка программирования PHP может работать в нескольких режимах. Он может быть интегрирован в веб-сервер в виде специального модуля или использоваться как отдельный сервис php-fpm. Аббревиатура FPM расшифровывается как Fastcgi Process Manager. Это сервис, который запускает несколько процессов, которые могут выполнять PHP скрипты. Процессы могут получить скрипты, которые надо выполнить по TCP или Unix сокетам.

Обычно php-fpm используется вместе с веб-сервером Nginx. В этой статье мы рассмотрим как выполняется настройка PHP-FPM для максимально эффективной работы на вашем сервере.

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

Менеджер процессов PHP-FPM может запускать несколько процессов обработчиков. Обычно для каждого отдельного сайта принято использовать отдельный обработчик, это позволяет распределить нагрузку и отслеживать статистику по каждому сайту. Поэтому есть общий конфигурационный файл php-fpm и конфигурационный файл для каждого обработчика, который обычно называется конфигурационным файлом пула. Обработчик принято называть пулом потому что на самом деле обработкой занимается не один процесс, а целая группа процессов, у каждого из которых есть несколько потоков. Всё это обеспечивает быстрое выполнение скриптов.

1. Установка компонентов

Сервис php-fpm поставляется вместе с интерпретатором php. Установка php-fpm Ubuntu выполняется такой командой:

sudo apt install php-fpm

Кроме того нам понадобится веб-сервер Nginx, потому что php-fpm чаще всего используется вместе с этим веб-сервером:

sudo apt install nginx

2. Конфигурационные файлы

В этой инструкции мы будем рассматривать настройку PHP-FPM на примере Ubuntu. Основной конфигурационный файл находится в такому пути:

Обратите внимание, что это не php.ini файл, а файл настройки именно FPM процессов. Файл php.ini находится в этой же папке:

А вот файлы конфигурации пулов находятся в каталоге /etc/php/7.4/fpm/pool.d/. По умолчанию там находится файл пула по умолчанию www.conf:

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

3. Создание пула

Скопируйте файл пула, например losst.conf в папке /etc/php/7.4/fpm/pool.d/ скопируйте в него содержимое файла www.conf. В конце статьи я приведу полностью рабочий конфигурационный файл, но лучше всё же использовать конфигурацию вашей версии PHP:

cp /etc/php/7.4/fpm/pool.d/www.conf /etc/php/7.4/fpm/pool.d/losst.conf

Теперь откройте этот файл в текстовом редакторе, например в vim:

sudo vi /etc/php/7.4/fpm/pool.d/losst.conf

Первым делом вам нужно выбрать имя пула в квадратных скобках в самой верхней части файла, например, losst, это имя можно использовать в конфигурации с помощью переменной $pool, а ещё оно будет отображаться в менеджере процессов:

Далее надо изменить группу и пользователя, от имени которых будут запускаться процессы пула. Это важно, поскольку у процесса должен быть доступ к файлам PHP, которые надо выполнить. Обычно в Ubuntu для таких целей используется пользователь и группа www-data. От имени этого же пользователя обычно запускается веб-сервер:

Обычно, если вы получаете ошибку permission denied при интерпретации php файлов в php-fpm, означает, что процесс php-fpm запущен от имени не того пользователя или включена строгая политика SELinux.

4. Настройка сокета

Дальше нужно настроить каким образом Nginx или другой веб-сервер будет обращаться к PHP-FPM. Как я уже говорил выше, можно настроить ожидание соединений на TCP порту. Обычно используются порты 9000, 9001, 9002 и так далее. В данном случае надо передать IP адрес на котором следует слушать и порт. Лучше использовать локальный IP адрес 127.0.0.1, чтобы к сервису никто не мог подключится из интернета. Второй вариант — использовать файловый Unix сокет, тогда надо просто передать путь к файлу сокета. В данном примере используется сетевой сокет 127.0.0.1:9000. Вид сокета не имеет значения, но сетевой использовать удобнее:

Если вы используйте файловый сокет, к нему должен быть доступ у веб-сервера, поэтому надо сделать владельцами файла того пользователя и группу, от имени которых запущен веб-сервер, в данном случае www-data и дать им все права на него:

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

Если сокет сетевой, то в этом нет необходимости. Для сетевого сокета можно дополнительно указать с каких адресов можно к нему подключаться. Например, только от 127.0.0.1:

5. Настройка процессов

С помощью параметра pm можно настроить сколько дочерних процессов будет запускаться для этого пула и когда. Есть три режима работы:

• dynamic — процессы создаются в зависимости от нагрузки и настроек, если нагрузки нет, всё равно работает определённое количество процессов;
• ondemand — процессы создаются как только возникает нагрузка;
• static — количество процессов всегда одинаковое, указанное в настройках.

Режим static не выгоден, потому что вне зависимости от нагрузки потребляется много памяти и процессорного времени на поддержание работы процессов. Более интересны режимы ondemand и dynamic. Давайте будем использовать режим dynamic. Этот режим имеет три настройки:

• pm.max_children — очень важный параметр, который работает для всех трёх режимов, означает максимально возможное количество дочерних процессов, если значение будет слишком маленьким, то при возрастании нагрузки, лимит исчерпается и ваш сайт начнёт тупить, если слишком большим — исчерпается оперативная память и что-то упадёт;
• pm.start_servers — указывает сколько процессов запускать при старте сервиса;
• pm.min_spare_servers — минимальное количество процессов в режиме ожидания (ничего не обрабатывающих), если количество процессов меньше, будет создан ещё один;
• pm.max_spare_server — максимальное количество процессов в режиме ожидания, если количество процессов будет больше, лишние будут завершены;

Для режима static надо указать только pm.max_children. Для режима ondemand кроме pm.max_children надо указать pm.process_idle_timeout этот параметр означает через какой промежуток времени простоя процесс будет завершен.

Давайте разберемся с режимом dynamic. Запускать много дочерних процессов при старте не надо, в большинстве случаев 2-3 будет достаточно:

Минимальное количество процессов в режиме ожидания тоже большое не нужно, это запас, чтобы php-fpm смог быстро обработать новые запросы не тратя время на запуск новых процессов. Однако это значение должно быть не меньше pm.start_servers, иначе ничего не заработает:

Максимальное количество процессов определяет как быстро процессы будут завершаться при падении нагрузки, можно оставить 10 процессов:

Параметр pm.max_children настройте под себя, обычно достаточно 20-30 процессов, но всё зависит от нагрузки и количества оперативной памяти, если памяти мало лучше пожертвовать производительностью и установить меньшее значение:

Почти готово. Но есть ещё одна проблема. Если дочерние процессы работают слишком долго, в них накапливаются утечки памяти, и рано или поздно на сервере память закончится. Чтобы этого избежать можно настроить автоматическое завершение процесса после выполнения определённого количества запросов, например, 1000:

6. Настройка статистики

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

7. Настройка php.ini

Несмотря на то, что есть общий файл php.ini для всех пулов, вы можете менять настройки прямо в файле пула, для этого используются директивы php_admin_value и php_admin_flag. Первая используется для установки строковых значений, а вторая — для флагов. У директив есть альтернативы: php_value и php_flag, они отличаются только тем, что их можно перезаписать с помощью функции ini_set, а значения заданные с помощью директив с приставкой admin перезаписать нельзя.

php_admin_flag[display_errors] = off php_admin_value[error_log] = /var/log/fpm-php.losst.log php_admin_flag[log_errors] = on php_admin_value[memory_limit] = 32M

Когда все настройки завершены, не забудьте сохранить изменения и перезапустить php-fpm:

sudo systemctl restart php7.4-fpm

8. Настройка веб-сервера

Для того чтобы всё протестировать придётся настроить ещё и веб-сервер. В конфигурационный файл виртуального хоста Nginx надо добавить такие строки:

\.php$ < fastcgi_split_path_info ^(.+?\.php)(/.*)$; if (!-f $document_root$fastcgi_script_name) < return 404; >include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; >

Первая секция позволяет смотреть статистику работы php-fpm открыв в браузере ссылку /status, которую мы ранее указали в настройках. Вторая секция обрабатывает всё остальные файлы php. Первая строка второй секции разбивает путь к скрипту по регулярному выражению на две части: $fastcgi_script_name и $fastcgi_path. Первая переменная нам понадобится в следующей же строчке, где с помощью условия проверяется существует ли такой файл, и если нет, то возвращается 404.

Дальше надо импортировать файл fastcgi_params, в котором передаются все переменные, которые потом будут доступны в массиве $_SERVER из скрипта. В следующей строчке объявляется ещё один важный параметр, которого нет в fastcgi_params, потому что он использует переменную $fastcgi_script_name, полученную ранее. Именно по нему php-fpm определяет путь к скрипту, который надо выполнить, если его не передать, вы получите пустой экран.

Последняя директива fastcgi_pass указывает как надо передавать данные php-fpm, сюда можно передать путь к файлу сокету, на котором слушает сервис или IP адрес и порт. В данном случае используется ранее настроенный 127.0.0.1:9000. После завершения настройки перезапустите Nginx:

sudo systemctl restart nginx

Теперь вы можете открыть в браузере страницу статистики, как видите всё работает:

Можно ещё создать файл phpinfo.php с текстом <?php phpinfo(); ?> в каталоге веб-сервера и посмотреть настройки php, например, memory_limit, заданный в файле конфигурации пула работает:

Настройка веб-сервера может очень сильно отличаться в зависимости от ваших требований. Здесь приведен только общий пример, чтобы проверить работоспособность и верность настройки.

PHP fpm

By Anusua Dutta

Introduction to PHP fpm

fpm in PHP stands for FastCGI Process Manager which is a pattern of implementation with some features that play quite a pivotal role with respect to website loading. Fpm in PHP includes a feature for advanced processing that nicely initiates any task and then closes that task without any intrusion. This feature has an added capability to adapt itself to any working environment comprising of ports, logging patterns, uploading of files with support for some special function to finishing requests by flushing data based on the configuration files present at the time of implementation.

How does PHP fpm Works?

PHP fpm has a very good working pattern that is useful in terms of loading and collecting data from databases and sites with heavy traffic and busy routines.

Web development, programming languages, Software testing & others

Let’s walk through the working flow which is quite useful to understand :

• PHP-fpm as its name suggests is a FastCGI process manager which basically makes use of a content management system in order to maintain the websites and to load the pages seamlessly to retrieve data conveniently.
• This feature makes use of high-level programming language like php which requires a compilation of scripts before it is fetched by the webserver because in case it reaches to web server earlier then it won’t be understood by the processor or hardware for understanding.
• Conventionally PHP never makes use of languages to be fed directly at the time of compilation rather it will first take its processor into grant then it will compile any of the PHP scripts through integrated web servers like CGI (common gateway interface), single-user PHP, and DSO(Dynamic Shared Object).
• At the time of executing any of the scripts mentioned is considered and then it is bonded to the process manager further for processing scripts and making other web servers understand it.
• After this, the server accepting the requests gets compiled and executed by the PHP scripts as part of an individual web server which will route the traffic towards the pointed or estimated traffic point or relocator.
• The configuration files included within the fpm PHP is responsible for executing all the processes related to the web server and then it provides the server with some permissions and ownership configurations.
• Making use of fpm and then providing processors these ways of resource handling and environment management makes the environment stable and accessible with ease.
• Provisioning of port, proxies, switch and other processor hardware within fpm makes it quite useful in terms of network establishment and manipulation with respect to these switches and ports.
• Thus, with all these justifications and statements it can also be said that indeed PHP fpm has made all these ways of processing including CGI, DSO, and mod_php quite old and not so recommended way of processing rather needs PHP fpm to be the focus area.
• All the disadvantages provided by CGI, DSO, and single-user PHP get updated seamlessly by the fpm easily that is why a recommended way of execution.
• Internally this PHP fpm has a different style of handling processes how? The very next question that comes into mind thus can be said that it behaves and works in master and slave fashion.
• The service layer it comprises is designed in some special way with some architecture and hierarchy maintained.
• It acts as a master when compared with master and slave mode so being a master it will comprise of the pool of other individual worker processes.
• As soon as the PHP server hits with the request to load any web page or interaction with the webserver then in that case first the server proxy gets used and then it gets landed on the PHP-FPM service layer which takes care of other functionality.
• Unix sockets with other switches and hosts make all the hosts and network ports listen to these ports present within the environment.
• Web routing internally is the main ingredient for bridging the gap between the service layer of fpm and server otherwise the interaction is not so easy to achieve.
• The traffic floating between the server and the service layer is also so huge that it varies dynamically by making the traffic to PHP scripts increase or decrease simultaneously.
• Another interesting fact is that although it supports the master and slave concept where the master is responsible for handling the server request the other workers are also somewhat responsible they are responsible in a way where they need to handle the traffic by maintaining the traffic periodically by spawning or another way round. Finally, the worker or say the slaves get terminated accordingly.
• Thus, these fpm PHP are quite a recommended way for dealing with PHP web servers and huge traffic with web pages.

Examples

• NGINX is one of the best examples supporting the PHP fpm as it makes use of the environment in the proper way by initiating a connection to the webserver in order to set the proxy server land to the service layer using some proper protocol. Followed by testing and configuration and then on top of it build releases can be made. It helps in creating the proxies for other clusters of workers and processors attached to the master which in this case is NGINX.
• Load balancers and Proxies with high availability clusters make use of PHP-fpm religiously without giving a second thought because of its adaptability and flexibility feature.

PHP fpm features

• Security
• Versatility
• Performance
• Reliable
• Configurable
• stability

Applications of PHP fpm in various fields

• web applications to cut off the time of loading the web page by maximum percentage.
• Application to monitor different hosts globally by using PHP-fpm.

For example Dynatrace

• For making High availability clusters using load balancers and proxy servers with FastCGI PHP fpm.
• NGINX with fpm-PHP for traffic routing at the time of configuring web servers.

Conclusion

PHP fpm is a very good alternative method with respect to web servers loading the data with huge traffic. It manages all the resources quite efficiently because of its flexibility and adaptability as a feature. Thus, it can be concluded that this feature is secured in terms of the data breach.

Recommended Articles

This is a guide to PHP fpm. Here we discuss how PHP fpm works along with applications, examples, and features. You may also have a look at the following articles to learn more –

Менеджер процессов FastCGI (FPM)

FPM (Менеджер процессов FastCGI) является альтернативной реализацией PHP FastCGI с несколькими дополнительными возможностями обычно используемыми для высоконагруженных сайтов.

продвинутое управление процессами с корректной (graceful) процедурой остановки и запуска;

возможность запуска воркеров с различными uid/gid/chroot-окружением, а также запуска на различных портах с использованием разных php.ini (замещение safe_mode);

логирование стандартных потоков вывода (stdout) и ошибок (stderr);

аварийный перезапуск в случае внезапного разрушения opcode-кэша;

поддержка ускоренной загрузки (accelerated upload);

"slowlog" — логирование необычно медленно выполняющихся скриптов (не только их имена, но также и их трассировки. Это достигается с помощью ptrace и других подобных утилит для чтения данных исполнения удаленных процессов);

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