Как стать автором
Обновить

Комментарии 22

А стоит ли держаться этого PHP?

Рейтинги падают, во всем мире популярность падает, хотя в России еще держится

Я это уже лет 20 слышу. Это как скорый и неизбежный крах доллара, только PHP.

Я помню как появился ruby с "рельсами" и говорили: "ну все, теперь php конец", потом появился react и прочие и тоже самое было. Потом go... С каждой новой волной чего-то нового - все ждут смерти PHP. Но он попрежнему живой)

Про крах PHP речи не идёт. RoR тоже в проде встречается. Однако статистика говорит об уменьшении доли техстека на рынке труда. По моим наблюдениям, компании перестали инвестировать в экосистему и специалистов ещё лет пять-шесть назад. Это заметно по ежегодным профильным конференциям. Почти все мои знакомые переехали на другие стеки. По рыночным причинам пришлось сделать тоже самое, оставив PHP для личных проектов и быстрого прототипирования.

А что там с профильными конфами? Вроде похапеконф на равне с гошной куда-то притулили в хл++. Всякие митапы и того и другого вполне себе существуют. Или гошка тоже затухает?

Сужу по десятку лет в PHPCon, Берлин. Митапы есть, особенно Wordpress сообщества. Но то понятно - 60% рынка CMS не шутка. Strapi и Directus пока не вышли на уровень "стандарта".

Продукт стабилен, особо ничего инновационного в нем не происходит вот и нет большого количества конф. Во вторых яп стало много поэтому размывает спецов и ощущение что php не популярный. На hh вакансий полно 🤷

А чем 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"

Киллер фича у нгинс в связке с апачем было терминирование медленных клиентов когда сети были медленными. Это серьезно разгружало апач. С fpm надобность в нем отпала.

Стоит отметить, что полученный результат не стоит воспринимать как абсолютно преимущество 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%, в всё остальное время - это ожидание данных от бд или другого сервиса.

Я очень давно писал на PHP4 и 5, потом ушёл в энтерпрайз. Недавно ковырялся с Simfony и честно говоря, лишь укрепился в своей мысли о том, что большие проекты лучше делать на других языках. С отладкой я так и не разобрался. Всё это хозяйство для работы, оно не цельное, лоскутное одеяло чего-то, больше похожего на хаки.

Ок, это может быть не Go, а может быть ASP.NET Core. Кстати, конкретно ASP.NET фреймворк проще чем Simfony.

При этом, мы вообще не думаем о том, кто такой этот Apache. У нас есть свой веб-сервер, достаточно добавить зависимость в проект и пару строчек кода. У нас доступна пошаговая отладка приложения без каких-то танцев с бубном.

Я честно не могу понять, какие возможности PHP перекрывают другие платформы? Что конкретно?

Шустрый с-подобный ООП язык, довольно простой для вайтшников, используется в куче проектов, и, как следствие, куча вакансий.
Вот его возможности.

Вот такой еще есть новый application server для php. Использует AMPHP компоненты и может в асинхронность.
https://phpstreamserver.dev/

Зарегистрируйтесь на Хабре, чтобы оставить комментарий