Комментарии 59
Но в целом согласен с вопросом и планирую дополнить раздел тестов более-менее реальными кейсами «сходить в базу» и «отрендерить HTML шаблон». Для себя тестиовал поведение Comet с PDO и Eloquent — последний оказался в два раза медленнее на простых вставках в базу.
использующий наработки команд SlimPHP и Workerman
По-моему, Вы используете не наработки этих команд, а их библиотеки
Как Comet поведёт себя при множестве блокирующих операций?
Хотелось бы понять так ли это и на сколько.
Тоже было огромное отличие в производительности, а потом заметил, что у меня op-cache не был установлен (оказалось что в centos это отдельный пакет). Установил op-cache и разница получилась всего в два раза. Возможно автор статьи тестировал с отключенным op-cache.
В принципе по графикам с латенси видно, что отличие всего в два раза.
А на графиках rps такое большое отличие потому что в php-fpm было мало воркеров.
Укажите пожалуйста сколько воркеров было использовано в тесте у comet и сколько у php-fpm.
В принципе даже на TechEmpower Benchmarks
видно, что workerman быстрее чистого php не более чем в 2 раза, ну и в 5 раз по сравнению с slim.
А у вас workerman+slim получился в 7 раз быстрее чем просто slim. Т.е. во время тестов было указано недостаточное количество воркеров и php-fpm просто захлёбывался, оказавшись в неравных условиях.
К слову, в TechEmpower Benchmarks чистый пхп добился таких высоких результатов, потому что они создают около 1000 воркеров. Из-за чего конечно сильно повышается расход оперативной памяти, но многие крупные проекты так и делают. Просто увеличивают количество воркеров. Память дешевле, чем переписывать весь код.
Я использую workerman уже очень давно и он хорошо себя показывает на микросервисах без блокирующих операций, но что-то более менее серьёзное, что ходит в базу и т.д. уже не даёт почти никаких преимуществ, но сильно усложняет разработку и деплой, поэтому в проде я его использую только там, где мне максимум приходится использовать redis.
Кусочек конфига, определяющий количество воркеров:
worker_processes auto;
worker_rlimit_nofile 200000;
events {
worker_connections 16384;
multi_accept off;
}
Кусочек конфига, определяющий количество воркеровЭто воркеры nginx, а я про воркеры php-fpm:
pm.max_children = 1024
В вашем фреймворке:
$worker->count = (int) shell_exec('nproc') * 4;т.е. в 4 раза больше чем ядер, поэтому мне было интересно сколько у вас было воркеров для пхп.
Кстати, у них в тесте сейчас количество воркеров уменьшается с 1012 до 512, если ядер два:
if [ $(nproc) = 2 ]; then sed -i «s|pm.max_children = 1024|pm.max_children = 512|g» /etc/php/7.4/fpm/php-fpm.conf; fi;
github.com/gotzmann/benchmarks
Результаты отрыва получились еще более впечатляющие :) Интересно понять, связано ли это на самом деле с конфигурированием, или все-таки workerman позволяет ускоряться до нереальных показателей.
В следующих версиях Comet планирую тоже поиграться с предзагрузкой и добавить более быстрые имплементации PSR-7 компонентов.
Тоже странно, почему нет RR в сравнении. Используем его в проде уже более полу-года (все php-приложения перевели на работу с ним, забыв про nginx+fpm) — полёт нормальный. Кстати, он довольно легко интегрируется с тем же Laravel, для чего написал и поддерживаю пакет avto-dev/roadrunner-laravel. По нашим тестам буст производительности (очень многое зависит от самих приложений) составил от 20 до 80 процентов.
Ну Spiral работает на RR раз в 5-7 быстрее Symfony, и это на точках с ORM (согласно тому же бенчмарку). Сравнивать микро сборки с фулл стеком достаточно ненадежное занятие.
Привет Антон :) Именно поэтому и было интересно посмотреть на бенчи указанного в посте решения под соусом RR. Кстати, дополню про "20 до 80 процентов" — это именно на "тяжелых" endpoints, условно-статичные (ping, static view) просто уходят в космос по сравнению с традиционным nginx+fpm.
В сторону Spiral пока лишь присматриваюсь, но и этот проект кажется очень интересным, обязательно что-нибудь на его основе сделаем.
Поскольку оверхеда на модули в спирали нет то можно уменьшать любую сборку. Вот пример с чисто ХТТП стеком — https://github.com/the-benchmarker/web-frameworks/tree/master/php/spiral
Как сказано в описании проекта на GitHub, Comet — это гибрид Slim и Workerman, приправленный собственной магией, которой будет больше в следующих релизах :)
Два года я писал микросервисы на Go… Однако, как всё хорошо начиналось :). Что подвергло REST-ы писать на РНР?
Не увидел в вашем примере ничего такого, что позволяло бы проще писать приложения с архитектурой REST. Хотя правильнее сказать — ничего такого, что заставляло бы писать этом стиле. Т.е. накладывало бы какие-то ограничения на программиста, которые исходят из ограничений описанных в REST.
У вас просто минималистичный web-фреймворк, который ни к чему не обязывает.
Мне кажется речь не совсем о том, что присутствует или не присутствует в вашем фреймворке(все понимают, через composer можно прикрутить что угодно), а речь о том, что тесты надо было демонстрировать хотя бы с загрузкой сервис-провайдеров/бандлов, с чтением конфигурации, заполнением контейнера зависимостей или сервис-локатора минимально необходимыми компонентами — сделать тот же "hello world", но включая минимальный набор того, что действительно понадобится во время разработки. Я почему-то уверен, что вы взяли тот же laravel и не выпиливали из него сервис-провайдеры, которые не будут использоваться(бродкасты, авторизация, вьюхи, сессии, очереди, dbal и.т.п), не отключали искоробочные глобальные middleware и прочее. Я не говорю, что оно сразу в одном вырастет, а в другом резко просядет, однако результаты будут немного справедливее, чем наблюдается сейчас… Отсюда и такие поспешные выводы про фрэймворк для "hello world".
github.com/gotzmann/benchmarks
Провел сравнительные тесты на машине Hetzner и разница между Comet и остальными фреймворками получилась еще более внушительной.
gotz прошу прощения, но какой смысл сравнивать проекты, которые работают по разным принципам? Если Вы воспользовались workerman в новом "фреймворке" получается, что это детище тоже работает асинхронно. Вы показали бэнчмарки сравнивая синхронные фреймворки с асинхронными. Может для справедливости к остальным фреймворка прикрутить Swool или что-то подобное и потом уже меряться, что скажете?
он всегда будет возвращать 500 ошибку…
public function setCounter(Request $request, Response $response, $args)
{
$body = (string) $request->getBody();
$json = json_decode($json);
if (!$json) {
return $response->withStatus(500);
}
self::$counter = $json->counter;
return $response;
}Когда такие косяки прямо в примерах в описании, сразу теряется доверие к автору, и пропадает желание использовать.
Comet — PHP-фреймворк для быстрых REST API