Comments 46
небольшой оффтоп:

Тот же reactphp используется дай бог на треть возможностей. Мало просто всё запихнуть в event loop, надо ещё гарантировать, что этот самый loop ничего не блокирует.
Именно поэтому он абсолютно не годится для всяких фреймворков. Воткнуть можно, но вреда будет больше, чем пользы (ну только в hello world'ах всё красиво)
Отлично — понятие довольно расплывчатое.
У того же php-pm под капотом будут ровно те же проблемы с блокирующим io. Ну т.е. мы не получаем эффекта от кооперативной многозадачности. Только минус к бутстрапингу.

Но, да, в случае с php-pm не будет одного из ключевых минусов reactphp с заблокированным лупом. Главным образом за счёт воркеров
Ну прощаться, конечно, рановато еще. Но начало заката — да, всё отчетливее
PHP так или иначе будет развиваться в сторону демонов. Вопрос лишь в том, какой ценой.
Если взять в рассчёт не простое echo, а +\- вменяемое приложение, то там есть ещё запас (php-pm и road runner не выгребают всё). На сколько разумно его использовать, глядя на «конкурентов» — хз, ведь это потребует очень большого разворота в головах php программистов.
Наверное, проще всё же взять какой-нибудь kotlin и не страдать.

до выхода php 8 с предполагаемой искоробочной асинхронностью основной менеджер процессов таки php-fpm. остальное — частные случаи для небольших приложений, где таки реально уследить за памятью и блокировками.

Вы перед тем, как выводы делать, посмотрели бы лучше на конфиг php-fpm.
Он кривой наглухо, результат с таким конфигом не удивителен.
На моей практике Swoole работает в 3-4 раза быстрее React PHP (увы, только их и сравнивал), кушая примерно на 1/4 меньше оперативки. Очень жаль, что его нет в бенчмарках, но подборка действительно крутая, спасибо.
Да Swoole крутая штука, с корутинами и асинхронным io, было бы интересно впихнуть сравнение в этот бенчмарк.
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).


Блин, я очепятался, простите. Конечно же я хотел написать «не треть/на четверть», а по привычке написал «в 3-4 раза». Посыпаю голову пеплом.
В статье странно указан диск
HDD: 50 GB SSD


В общем, плохие новости про php последнее время. Но в случае fpm я не вижу проблемы. Да 80% сайтов до сих пор работают на медленном апаче. Единицы сайтов хорошо оптимизированы.
Для них это все не грозит.
За счет чего unit такой быстрый? Чем он принципиально отличается от php-fpm?
Подскажите, у юнита есть url для получения статистики? Количество процессов, запросов, длинна очереди?
А какой хостинг/план? Хочу погонять кое что точно на таком же железе
Скажите, а в настройках PHP-FPM (www.conf) была проведена оптимизация этих параметров:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

А то чувствуется, что они остались по-умолчанию установленными…
все верно, как написано в статье:

Обработка запросов ограничивается двумя инстансами приложения (по числу ядер процессора).

Вот только max_children никогда не ставят равным количеству ядер. Кроме самой обработки запроса есть еще io операции, во время которых процессор простаивает. В это время могли обрабатываться другие воркеры. Первая ссылка из гугла по настройке hcbogdan.com/php/2016/09/16/php-fpm-dynamic
Хотелось сделать условия для всех более менее одинаковые, поэтому такие настройки. В других сервисах тоже по 2 воркера.
Условия — утилизировать железо, fpm не утилизировал. Разные подходы — разные настройки
Условия — утилизировать железо, fpm не утилизировал. Разные подходы — разные настройки

Поддерживаю. Бенчмарк, имеющий условие, что какая-то настройка (у всех значащая разное) равна двум, не имеет смысла.


mrsuh может быть добавите правильно настроенный PHP-FPM к результатам?

Заново построены все графики, где в легенде присутствует сервис php-fpm-80
Графики: 3.1, 3.3, 3.4, 4.1, 4.2, 4.3, 4.4
Да, где-то есть 80 где-то нет — понял, спасибо.
Идея теста и исполнение интересные, но вообще, похоже, вы померили менеджеры процессов со слишком простым кодом приложения, и скорее всего бОльшую часть процессорного времени в вашем тесте занимает работа менеджера, а не кода приложения. В то время как практическую ценность имел бы тест: как менеджер процессов ускоряет приложение, которое само по себе в режиме php-fpm ожирает хотя бы 0.05 процессорных секунд (не за счет моделей обработки соединений, а за счёт экономиях на инициализациях, например). Но здесь наверное основная проблема в том, что «правильный» тест нельзя сделать одним и тем же кодом.
>вы померили менеджеры процессов со слишком простым кодом приложения

Так и есть. Я как раз на днях тоже заценил, что простое приложение с парой запросов к бд и рендерингом шаблона не выдает те тысячи rps, которые декларируют авторы фреймворков
Мало будет один параметр поправить, нужно все зависимые тоже править:

pm.max_children — максимальное количество дочерних процессов
pm.start_servers — количество процессов при старте
pm.min_spare_servers — минимальное количество процессов, ожидающих соединения (запросов для обработки)
pm.max_spare_servers — максимальное количество процессов, ожидающих соединения (запросов для обработки)


В этой статье есть пример как это сделать: hcbogdan.com/php/2016/09/16/php-fpm-dynamic
Это совсем не правильно! В вашем случае должно быть 80!

pm.max_children — максимальное количество дочерних процессов
pm.start_servers — количество процессов при старте
pm.min_spare_servers — минимальное количество процессов, ожидающих соединения (запросов для обработки)
pm.max_spare_servers — максимальное количество процессов, ожидающих соединения (запросов для обработки)


Это же видно как на 1000 rps начал захлебываться — 72627

Спасибо, очень грамотный бенчмарк.


Будем изучать аномалию с rr-reboot выше 1000rps, в теории поведение должно быть такое-же как и reactphp-reboot.

Коллеги, не слова об ondemand, а только про dynamic. Почему?
FPM пока держит рынок, но закат близко.
мой опыт говорит что при пиковых нагрузках никаких динамических пре-форков, хоть динамик хоть он-деманд

нафоркать столько воркеров сколько тянет машина и с ними жить — иначе при резком скачке нагрузки все помрет
Абсолютно верный опыт.

Таким образом можно и метрики производительности иметь на единицу деплоя.
И знать сколько ресурсов потребуется.
И настроить алертинг на количество запросов/занятых воркеров, чтобы получить сигналы о том, что нужно подкинуть дровишек (железа, виртуалок, подов).
Чтобы тестировать производительность на единичных запусках на единичных виртуальных серваках надо быть очень большим оптимистом.
Если интересно, недавно запилил собственный бенчмарк с PHP-FPM, Apache mod_php и Nginx Unit. Спойлер: результаты отличаются от этой статьи.
Видео бенчмарка
net.core.somaxconn какое значение имеет, стандартное 128? для php-fpm это важно в общем-то, да и нестандартный ulimit я только у nginx увидел.
sysctl.conf и limits.conf для тестов были поправлены
в частности:
net.core.somaxconn = 2048
Only those users with full accounts are able to leave comments. Log in, please.