Как стать автором
Обновить

Комментарии 17

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

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

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


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


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

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

Удобная штука, мы используем в частности для очистки 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"

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

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

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

Публикации