На Хабре появилась очередная статья о том, как 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, которое лезет в базу" справился бы начинающий по стандартному мануалу. И у него не возникло бы ни одной серьёзной проблемы.