Если не брать Octane и просто сделать сравнительные бенчмарки: - приложения на Swoole в SWOOLE_BASE mode использующего только неблjкирующий IO; - приложения на RR с использованием блокирующего IO (неблокирующий там будет бесполезен); В таком сравнении Swoole уделывает RR в разы. На RR всё съедают накладные расходы на вытесняющую многозадачность, они никуда не делись, для выполнения PHP-кода в RR и FrankenPHP используются отдельные блокируемые процессы
PHP вместе с RR это те же блокирующиеся процессы на каждый HTTP-запрос. Выигрыш перед FPM за счёт того, что память процесса PHP не очищается после каждого запроса и вместо FastCGI используется какой-то другой IPC-механизм. Отсюда возможность переиспользовать память и соединения. Принципиально RR ничем от FPM не отличается, идея та же. Просто другая реализация. Swoole/AMPHP/ReactPHP обойдут RR по потреблению памяти и времени отклика на раз, потому что там фактически корутины. В RR корутин нет.
По поводу PHP это предубеждение. Всё зависит от конкретного кандидата. К тому же, C++, С# и Java(Kotlin, Scala) это очень развитые стэки с кучей возможностей. Они могут с Go потягаться по производительности и потреблению ресурсов, нет большого смысла с них переходить на Go (Go значительно выигрывает только тем, что у него нет VM, а по сравнению с C++ разве что значительно проще) и вакансий по Java и C# намного больше.
Проще получение подключения вынести куда-то повыше и передавать его в качестве аргумента. Также можно связывать подключение с id файбера при старте транзакции или при первом получении из пула. Решаемо.
Благодарю за содержательный комментарий, про "ромб" прям интересно. А не подскажете, где можно про перечисленные вами стратегии тестирования "ромб", "пирамида" и "перевёрнутая пирамида" и их связь с архитектурой приложения более подробно почитать?
STDOUT/ERR не должны особо мешать, т.к. если через fprintf туда писать, то должен будет использоваться буферизованный ввод/вывод, а это считай без блокирования.
Пакетов с блокирующими вызовами, да, конечно, больше, чем без. Но это практически для любой платформы (кроме Node.js и подобных) актуально.
C RoadRunner и FPM беда в том, что там для обработки каждого отдельного запроса нужен свой отдельный процесс, который будет блокироваться на блокирующих вызовах, а потому если много запросов - будет много процессов, а к этому операционки не готовы, вот если бы вместо процессов были треды...
Если резидент использует для перевода средств из-за рубежа в РФ систему KoronaPay (Золотая Корона) такие переводы тоже нужно включать в отчёт?
Если не брать Octane и просто сделать сравнительные бенчмарки:
- приложения на Swoole в SWOOLE_BASE mode использующего только неблjкирующий IO;
- приложения на RR с использованием блокирующего IO (неблокирующий там будет бесполезен);
В таком сравнении Swoole уделывает RR в разы. На RR всё съедают накладные расходы на вытесняющую многозадачность, они никуда не делись, для выполнения PHP-кода в RR и FrankenPHP используются отдельные блокируемые процессы
PHP вместе с RR это те же блокирующиеся процессы на каждый HTTP-запрос. Выигрыш перед FPM за счёт того, что память процесса PHP не очищается после каждого запроса и вместо FastCGI используется какой-то другой IPC-механизм. Отсюда возможность переиспользовать память и соединения. Принципиально RR ничем от FPM не отличается, идея та же. Просто другая реализация. Swoole/AMPHP/ReactPHP обойдут RR по потреблению памяти и времени отклика на раз, потому что там фактически корутины. В RR корутин нет.
Ну system design interview уже часто применяется. Эти алгоритмы и раньше то мало кому нужны были, а после появления LLM так вообще.
К любому проекту, даже без смены стэка человек привыкает в среднем 6 месяцев.
По поводу PHP это предубеждение. Всё зависит от конкретного кандидата. К тому же, C++, С# и Java(Kotlin, Scala) это очень развитые стэки с кучей возможностей. Они могут с Go потягаться по производительности и потреблению ресурсов, нет большого смысла с них переходить на Go (Go значительно выигрывает только тем, что у него нет VM, а по сравнению с C++ разве что значительно проще) и вакансий по Java и C# намного больше.
Я на PHP)
Жаль, что только для Java и С# разработчиков доступна такая возможность.
Вот не стал делать что-то. Так-то могу перевести и опубликовать и на английском, уровень языка достаточный имеется)
Проще получение подключения вынести куда-то повыше и передавать его в качестве аргумента. Также можно связывать подключение с id файбера при старте транзакции или при первом получении из пула. Решаемо.
Уметь
закрыватьпользоваться vim)И Borland C++ Builder)
Это статическими анализаторами не проверить нормально, сплошная динамика. Лучше в объекты такие данные гидрировать и всё.
Golang это отлично, но желательно и в нашем любимом и ламповом PHP тоже такое уметь делать и понимать как оно работает.
Благодарю за содержательный комментарий, про "ромб" прям интересно. А не подскажете, где можно про перечисленные вами стратегии тестирования "ромб", "пирамида" и "перевёрнутая пирамида" и их связь с архитектурой приложения более подробно почитать?
STDOUT/ERR не должны особо мешать, т.к. если через fprintf туда писать, то должен будет использоваться буферизованный ввод/вывод, а это считай без блокирования.
Пакетов с блокирующими вызовами, да, конечно, больше, чем без. Но это практически для любой платформы (кроме Node.js и подобных) актуально.
C RoadRunner и FPM беда в том, что там для обработки каждого отдельного запроса нужен свой отдельный процесс, который будет блокироваться на блокирующих вызовах, а потому если много запросов - будет много процессов, а к этому операционки не готовы, вот если бы вместо процессов были треды...
Да, файберы и на сервере вебсокетов(который лучше всего для чата) смогут пригодиться, пример тоже можно сделать, пока простой HTTP-сервер