Комментарии 22
А стоит ли держаться этого PHP?
Рейтинги падают, во всем мире популярность падает, хотя в России еще держится
Я это уже лет 20 слышу. Это как скорый и неизбежный крах доллара, только PHP.
Я помню как появился ruby с "рельсами" и говорили: "ну все, теперь php конец", потом появился react и прочие и тоже самое было. Потом go... С каждой новой волной чего-то нового - все ждут смерти PHP. Но он попрежнему живой)
Про крах PHP речи не идёт. RoR тоже в проде встречается. Однако статистика говорит об уменьшении доли техстека на рынке труда. По моим наблюдениям, компании перестали инвестировать в экосистему и специалистов ещё лет пять-шесть назад. Это заметно по ежегодным профильным конференциям. Почти все мои знакомые переехали на другие стеки. По рыночным причинам пришлось сделать тоже самое, оставив PHP для личных проектов и быстрого прототипирования.
А что там с профильными конфами? Вроде похапеконф на равне с гошной куда-то притулили в хл++. Всякие митапы и того и другого вполне себе существуют. Или гошка тоже затухает?
Сужу по десятку лет в PHPCon, Берлин. Митапы есть, особенно Wordpress сообщества. Но то понятно - 60% рынка CMS не шутка. Strapi и Directus пока не вышли на уровень "стандарта".
А чем wordpress заменить? Это же самая используемая в мире cms, чуть ли не 40% сайтов на нем. Php с нами надолго, как C и Js.
Работа веб-сервера в связке Nginx и Apache с использованием mod_php демонстрирует значительное увеличение производительности.
Ваши графики этого не показывают. Надо или отредактировать текст, или разобраться, почему в графиках нарисована ерунда.
Apache mod_php рекомендуется использовать вместе с Nginx в качестве сервера для статики в проектах, где нет больших нагрузок и требуется минимальная настройка.
Это какая-то логика системы чат жипити. Настройка энжинкса в качестве прокси ничуть не проще, чем настройка в качестве основного сервера. Но при этом во втором случае мы полностью избавляемся от апача. То есть вместо того, чтобы сделать две сущности (апач+модпхп либо энжинкс+фпм), настраиваем три и говорим всем, что это проще.
На мой взгляд, единственная причина использовать этого франкенштейна - древний легаси код, половина которого написана в файлике .htaccess. А не мифическая "минимальная настройка".
И fpm ещё какой-то павлин написал.
Так сложилось исторически. Обратная совместимость если хотите.
Сначала появился Apache и куча проектов/кода была написана с расчетом на него. А потом появился NGinx и одним из частых кейсов его использования стала отдача статики.
Если быть совсем точным то: "При рассмотрении среднестатистического сайта (1 запрос html + 100 запросов к статике на каждую страницу) и в условиях ограниченной RAM работа веб-сервера в связке Nginx и Apache с использованием mod_php демонстрирует значительное увеличение производительности по сравнению с Apache-only"
Стоит отметить, что полученный результат не стоит воспринимать как абсолютно преимущество swoole/rr/franken над fpm.
Нужно принимать во внимание количество процессов-воркеров, а так же время работы полезной нагрузки.
Да, swoole/rr/franken экономят время начала обработки запроса, но количество памяти занимаемой фреймворком и пользовательским кодом не уменьшается. Поэтому потребление памяти примерно равно количеству воркер-процессов. А использовать существенно меньше процессов получится только если время обработки запроса сопоставимо с временем прогрузки фреймворка - около 20мс.
Отсюда вывод - если ваши запросы отрабатывают за сотни миллисекунд, то не стоит ожидать экономии памяти, уменьшив время на 20мс. Тем более что, например тот же swoole дополнительно запускает ещё несколько процессов: сама консолтная команда octane:start, мастер-процесс swoole, manager-процесс swoole, как минимум один task-воркер.
Все верно, это не серебряная пуля. Мы как раз и проводили тестирование в контексте ненулевого оверхеда на инициализацию фреймворка.
FPM тоже не золотое решение, но у него например больше возможностей отладки (в том числе и медленных запросов).
Ну а если нам нужен NTLM, то все равно придется вместо или рядом ставить Apache
Верно, вечноживущие сервера приложений не экономят память (а скорее наоборот тратят её больше так как постоянно кто-то забывает что-то выгружать/очищать), но вот CPU экономят прилично. По нашим наблюдениям (rr+spiral vs fpm+yii2) выигрыш был +/- 2x уменьшение утилизации CPU при таком же rps.
Спасибо, полезная статья.
Я конечно не эксперт,но мне кажется имеет смысл не выжимать что-то из php ,а перейти на go или другие более быстрые и современные языки.
PHP - современный язык.
Php не медленный. Скорость интерпретации php кода выше чем у питона. Ну и если речь не про игры или архиваторы, то скорость в этом понимании не так уж и важна.
Важна реализация веб-сервера. Можно на интерпретируемом языке написать более производительный сервер чем некоторые на компилируемом.
Это, кстати, перекликается с темой статьи. В ней не рассказано как получить максимум производительности на php, в ней рассказано как ускорить классические php приложения с минимальными изменениями.
Настоящее ускорение получается при переходе на event loop. Тогда один воркер-процесс сможет обрабатывать кратно больше запросов, ведь в типичной для веб-серверов io-bound нагрузке доля работы воркера всего 10-20%, в всё остальное время - это ожидание данных от бд или другого сервиса.
Go язык быстрый только он php он не ровная в сфере разработки вэб.
Я очень давно писал на PHP4 и 5, потом ушёл в энтерпрайз. Недавно ковырялся с Simfony и честно говоря, лишь укрепился в своей мысли о том, что большие проекты лучше делать на других языках. С отладкой я так и не разобрался. Всё это хозяйство для работы, оно не цельное, лоскутное одеяло чего-то, больше похожего на хаки.
Ок, это может быть не Go, а может быть ASP.NET Core. Кстати, конкретно ASP.NET фреймворк проще чем Simfony.
При этом, мы вообще не думаем о том, кто такой этот Apache. У нас есть свой веб-сервер, достаточно добавить зависимость в проект и пару строчек кода. У нас доступна пошаговая отладка приложения без каких-то танцев с бубном.
Я честно не могу понять, какие возможности PHP перекрывают другие платформы? Что конкретно?
Вот такой еще есть новый application server для php. Использует AMPHP компоненты и может в асинхронность.
https://phpstreamserver.dev/
Выжимаем максимум скорости из PHP