Запускаем PHP-скриптики через php-fpm без web-сервера. Или свой FastCGI-клиент (под капотом)

[edogs]

Любопытная статья.
А почему было не использовать собственно nginx, а скрипты дергать по http?

[fm-00]

Из скрипта тогда нужно было бы отправлять запросы к nginx, а он в свою очередь возвращал бы их назад, получается лишнее звено. Но в итоге как я и написал в статье реализовали этот компонент совсем по другому через rabbit. В этой же статье реализация не главное, основное тут это разбор протокола

[Yeah]

https://github.com/spiral/roadrunner не пробовал?

[fm-00]

Спасибо, буду иметь это ввиду. Тем более на Golang, стоит изучить

[SerafimArts]

Кажется там изучать особо ничего и не надо, ибо с Go (с языком имею ввиду) общаться почти не придётся. Ну и как бы воркеры\очереди\форки (как угодно можно называть) там из коробки идут.

[vp7]

Какой-то странный подход.

Если нужно было прослушать обмен, то wireshark вам в руки. Возможно, он даже сам протокол декодировать сможет.

Ну и отдельно совершенно непонятно, почему php_fpm использовать можно, а поставить перед ним nginx, который будет принимать запросы и отдавать в php_fpm — нет.
Экономия памяти? Да там копейки…
Лишняя точка отказа? Тоже не факт, nginx наоборот может балансировать трафик на несколько демонов php_fpm и отрабатывать ошибки.

[fm-00]

Совершенно не претендую на то что данный подход хорош, и не сомневаюсь что можно было реализовать все это намного лучше (собственно сама первоначальная задача и была реализована по другому).
В этой статье основное что хотелось рассказать — это как работает протокол, и как на php можно с ним работать. Конечно врядли php лучший выбор для этого в реальном коде, но для разбора теории вполне норм.

[ZurgInq]

Из необычного применения такой интеграции php -> (fast-cgi) php-fpm -> php можно придумать следующую схему. Простой брокер сообщений в виде php демона и php-fpm как балансировщик воркеров. В такой схеме воркеры получат преимущества короткоживущего процесса без хранения состояния.

[fm-00]

Да что то такое и планировали изначально, но к сожалению из-за нехватки времени быстро не получилось реализовать, воспользовались готовым решением.

[Merkat0r]

Supervisor

[fm-00]

Непонятно как это относится к статье, там не про шаблоны, там про реализацию и принципиальную схему работы протокола FastCGI через PHP

[dukei]

А чем cgi-fcgi не подошла? Она вроде бы придумана специально для решения вашей проблемы.
https://www.opennet.ru/man.shtml?topic=cgi-fcgi&category=1&russian=2

[lCodeMakerl]

Удобная штука, мы используем в частности для очистки opcache при деплое без перезапуска php-fpm.

Примерно так, может кому пригодится:

#!/bin/bash

WEBDIR="/var/local/www"
RANDOM_NAME=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 13).php

sudo -u www-data mkdir -p ${WEBDIR}/opcache
sudo -u www-data touch ${WEBDIR}/opcache/${RANDOM_NAME}

echo "<?php echo \"\\t\"; if (function_exists('opcache_reset')) echo (opcache_reset() ? 'OK' : 'FAIL'); else echo 'FAIL'; ?>" > ${WEBDIR}/opcache/${RANDOM_NAME}

printf "\nTCP/IP\n\t"
sudo -u www-data bash -c "SCRIPT_NAME=/${RANDOM_NAME} SCRIPT_FILENAME=${WEBDIR}/opcache/${RANDOM_NAME} REQUEST_METHOD=GET cgi-fcgi -bind -connect 127.0.0.1:9000"

printf "\nSocket\n\t"
sudo -u www-data bash -c "SCRIPT_NAME=/${RANDOM_NAME} SCRIPT_FILENAME=${WEBDIR}/opcache/${RANDOM_NAME} REQUEST_METHOD=GET cgi-fcgi -bind -connect /var/run/php/php7-fpm.sock"

rm -R ${WEBDIR}/opcache

printf "\n\n"

[sasha_pe]

Может быть я не прав, но почему бы не использовать AWS Lambda или Yandex Cloud Functions?

[ReDev1L]

Как "разбор протокола" не плохо. Но это адский ад. Это вообще лишнее, для "дергания" скриптов.

[fm-00]

Да именно как разбор, просто даже зная теорию, пока сам не реализуешь это на практике хорошего понимания не получается (ну у меня по крайней мере)

[Gemorroj]

спасибо, очень интересно.
отмечу только, что готовых fastcgi клиентов вполне достаточно https://packagist.org/?query=fastcgi

[Yan_Alex]

@fm-00 почему вы пишете что подключаете fpm как сокет, а конфигурация у вас по tcp?

[Arkady23]

Написал свой http/https сервер на C#. Убыстрил Python, как интерпретатор за счет маленького скрипта initcgi.py, у которого уже всё готово, он только ждет подключение. После отработки и ответа скрипт закрывается и запускается новый, который ждет дальше. Таких скриптов несколько десятков, все параллельно ждут запросы. Пример скрипта:
import runpy
script = input() # Чтение имени скрипта
if script:
runpy.run_path(script) # Запуск скрипта обработчика запроса

Серверы и скрипт для быстрого cgi здесь Arkady23/http.net-https.net: Multithreaded http.net and https.net servers for Windows.