На Хабре появилась очередная статья о том, как php пытаются на | Cross Join - канал о разработке

На Хабре появилась очередная статья о том, как php пытаются натянуть на хайлоад, используя для этого костыли swoole.

Статья потрясающая, ведь в ней перечислены все минусы этого подхода по сравнению с Go, Node и т.д., а выводы сделаны противоположные здравому смыслу.

В статье api, которое пишет в базу, нагрузка всего 300rps.

1) Приложение жрет 2 гига памяти и 8 ядер cpu. Ну хз, Go сожрало бы в несколько раз меньше. У меня микросервисы обычно потребляют в разы меньше при гораздо большей нагрузке. Хотя, конечно, зависит от конкретики приложения.

2) раздел "простота инфраструктуры", цитирую:

"...внутри контейнера будет всего 11 процессов: 1 tini (supervisor)+entrypoint, 1 master процесс, 1 manager процесс и 8 worker процессов."

Вы чо, ребят? Какая тут простота? Особенно учитывая, что они зачем-то перезапускают процессы воркеров раз в час.

Image весит всего 120 мегабайт. Ну неплохо, но если это так важно, то в Go можно оставить вообще один бинарник (FROM scratch), и образ будет весить по сути вообще около нуля.

3) чтобы добиться постоянного соединения к бд и редису, пришлось написать несколько оберток к библиотекам и драйвер к doctrine.

4) 4ms уходит на обработку запроса без логики (пустой запрос или даже 404). Сорян, но это очень много.

5) в течение месяца после выкатки они вылавливали странные ситуации. Что-то там текло при коннекте к посгресу и тд.

Итог) Вывод делают такой: php закапывать рано, все норм.

Блин. Если бы в статье был упор на удобство написания кода, то я бы это купил и пошарил бы везде. Синтаксис php во многом удобнее. Но статья про хайлоад и производительность, блин.

Отдельно хочу заметить, что описанное в статье могла намутить только команда прокачанных php-синьоров, которые готовы ловить и фиксить необычные проблемы. А на Go с задачей "highload api, которое лезет в базу" справился бы начинающий по стандартному мануалу. И у него не возникло бы ни одной серьёзной проблемы.