Причитал статью и вспомнил высказывание: "- Вы не любите котов!? — Вы просто не умеете их правильно готовить!"
Как чужой опыт, статья конечно имеет право быть, но ИМХО выглядит она как хвалебная песня в честь Linux, Go и Erlang.
Можно было просто сказать, что наша команда знает Linux, Go и Erlang и поэтому в условиях дефицита времени для достижения цели выбрали в качестве инструмента, то что мы лучше всего знаем. (И это единственно правильное решение).
Но недостатки других решений или преимущества (Linux, Go и Erlang) совсем не очевидны.
Чем плох PHP и в частности PHP Workerman не понятно!
«Poll vs. Epoll»… А где kqueue/kevent?
Или kqueue настолько не эфективен что не заслужил упоминания? Да,… не кросплатформенно… да, с этим умеют работать только BSD системы и некоторые комерческие системы используют подобный подход.
Но согласитесь, что это проблема Linux, а не PHP Workerman!
NGINX + PHP-FPM умеют использовать эфективный kqueue и вместе они прекрасно масштабируются «по самое не могу»!
«PHP Workerman — Код находится на уровне PHP 5.3 и не соответствует никаким стандартам.» — простите, а каким конкретно стандартам он должен соответствовать?!
У меня код работал на PHP 7.1, но если автор тестировал на сервере с PHP 5.3, то это даже не проблема настроек PHP… и уж тем более не проблема PHP Workerman. И из этого не следует, что он не позволяет реализовывать высоконагруженные проекты…
Скажем прямо, просто Вы выбрали другой путь… свой путь.
В том то и дело, что PHP отлично летает… по крайней мере до тех пор пока ему булыжник на шею не цепляют.
Концепция «рожден чтобы умирать» это от того что PHP — скриптовый язык, который изначально задумывался для веба, и чтобы следовать простому процессу: получить запрос, обработать его, отобразить вывод и умереть.
А зачем нужны 5 классов «встроенного autoload» если в конце он все равно вызывается spl_autoload_register?
Ну это еще ладно… можно объяснить унификацией подключения сторонних библиотек.
Но в чем круть от писанины автора: «return new JsonResponse(...)», вместо return json_encode(...) ?!
А если этот никчемный класс (JsonResponse) порождается 100 раз в секунду?
ЗЫ. Давайте не забывать, что PHP — язык рожденный умирать! А OOP — это всегда медленно…
PHP + OOP = «hello, Highload»
Предлагаю переименовать публикацию :-)
The best! Не в бровь, а в глаз…
Как чужой опыт, статья конечно имеет право быть, но ИМХО выглядит она как хвалебная песня в честь Linux, Go и Erlang.
Можно было просто сказать, что наша команда знает Linux, Go и Erlang и поэтому в условиях дефицита времени для достижения цели выбрали в качестве инструмента, то что мы лучше всего знаем. (И это единственно правильное решение).
Но недостатки других решений или преимущества (Linux, Go и Erlang) совсем не очевидны.
Чем плох PHP и в частности PHP Workerman не понятно!
«Poll vs. Epoll»… А где kqueue/kevent?
Или kqueue настолько не эфективен что не заслужил упоминания? Да,… не кросплатформенно… да, с этим умеют работать только BSD системы и некоторые комерческие системы используют подобный подход.
Но согласитесь, что это проблема Linux, а не PHP Workerman!
NGINX + PHP-FPM умеют использовать эфективный kqueue и вместе они прекрасно масштабируются «по самое не могу»!
«PHP Workerman — Код находится на уровне PHP 5.3 и не соответствует никаким стандартам.» — простите, а каким конкретно стандартам он должен соответствовать?!
У меня код работал на PHP 7.1, но если автор тестировал на сервере с PHP 5.3, то это даже не проблема настроек PHP… и уж тем более не проблема PHP Workerman. И из этого не следует, что он не позволяет реализовывать высоконагруженные проекты…
Скажем прямо, просто Вы выбрали другой путь… свой путь.
Но я, пожалуй, еще чуток побуду динозавром…
В том то и дело, что PHP отлично летает… по крайней мере до тех пор пока ему булыжник на шею не цепляют.
Концепция «рожден чтобы умирать» это от того что PHP — скриптовый язык, который изначально задумывался для веба, и чтобы следовать простому процессу: получить запрос, обработать его, отобразить вывод и умереть.
Ну это еще ладно… можно объяснить унификацией подключения сторонних библиотек.
Но в чем круть от писанины автора: «return new JsonResponse(...)», вместо return json_encode(...) ?!
А если этот никчемный класс (JsonResponse) порождается 100 раз в секунду?
ЗЫ. Давайте не забывать, что PHP — язык рожденный умирать! А OOP — это всегда медленно…
PHP + OOP = «hello, Highload»
Предлагаю переименовать публикацию :-)