Комментарии 46
del.
небольшой оффтоп:
Тот же reactphp используется дай бог на треть возможностей. Мало просто всё запихнуть в event loop, надо ещё гарантировать, что этот самый loop ничего не блокирует.
Именно поэтому он абсолютно не годится для всяких фреймворков. Воткнуть можно, но вреда будет больше, чем пользы (ну только в hello world'ах всё красиво)
Тот же reactphp используется дай бог на треть возможностей. Мало просто всё запихнуть в event loop, надо ещё гарантировать, что этот самый loop ничего не блокирует.
Именно поэтому он абсолютно не годится для всяких фреймворков. Воткнуть можно, но вреда будет больше, чем пользы (ну только в hello world'ах всё красиво)
Смотря как этот react готовить. Тот же php-pm отлично работает.
Отлично — понятие довольно расплывчатое.
У того же php-pm под капотом будут ровно те же проблемы с блокирующим io. Ну т.е. мы не получаем эффекта от кооперативной многозадачности. Только минус к бутстрапингу.
Но, да, в случае с php-pm не будет одного из ключевых минусов reactphp с заблокированным лупом. Главным образом за счёт воркеров
У того же php-pm под капотом будут ровно те же проблемы с блокирующим io. Ну т.е. мы не получаем эффекта от кооперативной многозадачности. Только минус к бутстрапингу.
Но, да, в случае с php-pm не будет одного из ключевых минусов reactphp с заблокированным лупом. Главным образом за счёт воркеров
Выводов можно было сделать больше. Вроде: прощай php-fpm.
Ну прощаться, конечно, рановато еще. Но начало заката — да, всё отчетливее
PHP так или иначе будет развиваться в сторону демонов. Вопрос лишь в том, какой ценой.
Если взять в рассчёт не простое echo, а +\- вменяемое приложение, то там есть ещё запас (php-pm и road runner не выгребают всё). На сколько разумно его использовать, глядя на «конкурентов» — хз, ведь это потребует очень большого разворота в головах php программистов.
Наверное, проще всё же взять какой-нибудь kotlin и не страдать.
Если взять в рассчёт не простое echo, а +\- вменяемое приложение, то там есть ещё запас (php-pm и road runner не выгребают всё). На сколько разумно его использовать, глядя на «конкурентов» — хз, ведь это потребует очень большого разворота в головах php программистов.
Наверное, проще всё же взять какой-нибудь kotlin и не страдать.
до выхода php 8 с предполагаемой искоробочной асинхронностью основной менеджер процессов таки 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).
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).
Блин, я очепятался, простите. Конечно же я хотел написать «не треть/на четверть», а по привычке написал «в 3-4 раза». Посыпаю голову пеплом.
В статье странно указан диск
В общем, плохие новости про php последнее время. Но в случае fpm я не вижу проблемы. Да 80% сайтов до сих пор работают на медленном апаче. Единицы сайтов хорошо оптимизированы.
Для них это все не грозит.
HDD: 50 GB SSD
В общем, плохие новости про php последнее время. Но в случае fpm я не вижу проблемы. Да 80% сайтов до сих пор работают на медленном апаче. Единицы сайтов хорошо оптимизированы.
Для них это все не грозит.
За счет чего unit такой быстрый? Чем он принципиально отличается от php-fpm?
Для каждого языка, в том числе и PHP, собирается модуль для работы с nginx unit. Наверняка в таком модуле есть оптимизации и кеширование.
github.com/nginx/unit/blob/db631917190c44b3b55a15e4e5e88aa92e6b5334/src/nxt_php_sapi.c
github.com/nginx/unit/blob/db631917190c44b3b55a15e4e5e88aa92e6b5334/src/nxt_php_sapi.c
У него другая архитектура. Я рассказывал об этом в докладе на БИФ2018: yadi.sk/i/yczMbKccJ7Ujkg (где-то с 16 минуты).
Подскажите, у юнита есть url для получения статистики? Количество процессов, запросов, длинна очереди?
По просьбам зрителей ссылка на слайды: pp.nginx.com/vbart/slides/BIF2018.pdf
А какой хостинг/план? Хочу погонять кое что точно на таком же железе
Скажите, а в настройках PHP-FPM (www.conf) была проведена оптимизация этих параметров:
А то чувствуется, что они остались по-умолчанию установленными…
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
А то чувствуется, что они остались по-умолчанию установленными…
Все конфиги лежат в репо, так что вы можете сами их посмотреть для каждого сервиса.
Конкретно для php-fpm конфигурация тут:
github.com/mrsuh/php-load-test/blob/master/docker/php-fpm/php-fpm/php-fpm.conf
Конкретно для php-fpm конфигурация тут:
github.com/mrsuh/php-load-test/blob/master/docker/php-fpm/php-fpm/php-fpm.conf
max_children=2…
все верно, как написано в статье:
Обработка запросов ограничивается двумя инстансами приложения (по числу ядер процессора).
Вот только max_children никогда не ставят равным количеству ядер. Кроме самой обработки запроса есть еще io операции, во время которых процессор простаивает. В это время могли обрабатываться другие воркеры. Первая ссылка из гугла по настройке hcbogdan.com/php/2016/09/16/php-fpm-dynamic
Хотелось сделать условия для всех более менее одинаковые, поэтому такие настройки. В других сервисах тоже по 2 воркера.
Условия — утилизировать железо, fpm не утилизировал. Разные подходы — разные настройки
Условия — утилизировать железо, fpm не утилизировал. Разные подходы — разные настройки
Поддерживаю. Бенчмарк, имеющий условие, что какая-то настройка (у всех значащая разное) равна двум, не имеет смысла.
mrsuh может быть добавите правильно настроенный PHP-FPM к результатам?
Добавил сервис php-fpm-80 c
pm.max_children = 80
ну а графики все построены со старыми настройками?
Заново построены все графики, где в легенде присутствует сервис php-fpm-80
Графики: 3.1, 3.3, 3.4, 4.1, 4.2, 4.3, 4.4
Графики: 3.1, 3.3, 3.4, 4.1, 4.2, 4.3, 4.4
Да, где-то есть 80 где-то нет — понял, спасибо.
Идея теста и исполнение интересные, но вообще, похоже, вы померили менеджеры процессов со слишком простым кодом приложения, и скорее всего бОльшую часть процессорного времени в вашем тесте занимает работа менеджера, а не кода приложения. В то время как практическую ценность имел бы тест: как менеджер процессов ускоряет приложение, которое само по себе в режиме php-fpm ожирает хотя бы 0.05 процессорных секунд (не за счет моделей обработки соединений, а за счёт экономиях на инициализациях, например). Но здесь наверное основная проблема в том, что «правильный» тест нельзя сделать одним и тем же кодом.
Идея теста и исполнение интересные, но вообще, похоже, вы померили менеджеры процессов со слишком простым кодом приложения, и скорее всего бОльшую часть процессорного времени в вашем тесте занимает работа менеджера, а не кода приложения. В то время как практическую ценность имел бы тест: как менеджер процессов ускоряет приложение, которое само по себе в режиме php-fpm ожирает хотя бы 0.05 процессорных секунд (не за счет моделей обработки соединений, а за счёт экономиях на инициализациях, например). Но здесь наверное основная проблема в том, что «правильный» тест нельзя сделать одним и тем же кодом.
Мало будет один параметр поправить, нужно все зависимые тоже править:
В этой статье есть пример как это сделать: hcbogdan.com/php/2016/09/16/php-fpm-dynamic
pm.max_children — максимальное количество дочерних процессов
pm.start_servers — количество процессов при старте
pm.min_spare_servers — минимальное количество процессов, ожидающих соединения (запросов для обработки)
pm.max_spare_servers — максимальное количество процессов, ожидающих соединения (запросов для обработки)
В этой статье есть пример как это сделать: hcbogdan.com/php/2016/09/16/php-fpm-dynamic
Это совсем не правильно! В вашем случае должно быть 80!
Это же видно как на 1000 rps начал захлебываться — 72627
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 пока держит рынок, но закат близко.
FPM пока держит рынок, но закат близко.
Чтобы тестировать производительность на единичных запусках на единичных виртуальных серваках надо быть очень большим оптимистом.
Если интересно, недавно запилил собственный бенчмарк с PHP-FPM, Apache mod_php и Nginx Unit. Спойлер: результаты отличаются от этой статьи.
Видео бенчмарка
Видео бенчмарка
Вторая серия бенчмарка, обновлённая и дополненная: www.youtube.com/watch?v=-k9Hj8B1t9M
net.core.somaxconn какое значение имеет, стандартное 128? для php-fpm это важно в общем-то, да и нестандартный ulimit я только у nginx увидел.
Апач бы сюда )))) для полной картины, а так все круто
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравниваем PHP FPM, PHP PPM, Nginx Unit, React PHP и RoadRunner