Comments 7
Не очень понятно, что именно подразумевается под «этим чудом» и о каком тестировании идет речь. Если речь идет о том, как тестировать API, то ответ простой: так же, как любое другое API. Клиент генерируется автоматически. Остается лишь написать ассерты.

Здорово!


Мы написали свой 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 потихоньку происходит изменение подхода к построению приложений. Лично я надеюсь, что в будущем появится больше удобств для создания фуллстек-приложений и со стороны интерпретатора.
Only those users with full accounts are able to leave comments. Log in, please.