Комментарии 7
Здорово!
Мы написали свой PHP процесс менеджер примерно для таких же целей — https://github.com/spiral/roadrunner
Только вместо FAST-CGI работаем с несколькими демонизированными PHP процессами через пайпы и бинарный протокол (без бутлоада получается ускорить отзывчивость точки раз в 10-30).
А насчет оптимизации производительности: у вас интересный порядок цифр 10-30 раз. Если не секрет, с чем производилось сравнение?
У нас была цель внедрить RPC точки в старый код (+queue в некоторых случаях), производительность это просто побочный эффект выноса коммуникации в сам процесс. Давно зреет идея повесить GRPC прокси сверху, но для начала хотим закончить PSR-7 сервер на этой штуке.
Фреймворки работают на ура, главное чтобы компоненты были написаны правильно и не текла память. Плюс библиотека включает failswitch для корректного завершения процесса в случае каких-либо проблем.
Сравнивали со своим же фреймворком (spiral, лежит в той же огранизации), но под nginx+php-fpm. Чем больше бутлоад проекта тем больше разница в производительности. В некоторых тестах с участием баз данных удавалось выжать разницу в 65 раз.
главное чтобы компоненты были написаны правильно и не текла память
Из-за этого мы не рискнули применять такой подход. Ранее рассматривали вариант перехода на PHP-PM, который работает по схожему принципу. Но у нас довольно много сишных екстеншенов используется и стороннего кода из Composer. Сложно ручаться за все библиотеки.
И еще страшно за транзакции/сейвпоинты в БД. Если где-то в одном месте она не закрыта случайно, то, кажется, все следующие запросы будут под угрозой. Навскидку приходит только либо отдать контроль за этим приложению (ввести счетчик и надеяться, что все будут открывать транзакции через контроллируемый нами метод), либо перед обработкой запроса ходить в БД за информацией о транзакции на этом подключении.
В любом случае хорошо, что в мире PHP потихоньку происходит изменение подхода к построению приложений. Лично я надеюсь, что в будущем появится больше удобств для создания фуллстек-приложений и со стороны интерпретатора.
Дружим gRPC с долгоживущим проектом, PHP и фронтендом