PHP-боярин подобен человеку-пауку.
Не потому, что у него восемь лапок (и, кстати, не потому, что у него лапки).
А потому, что главный лозунг человека-паука: "с большой силой приходит и большая ответственность".
На эту тему есть моя любимая шутка, которая, к сожалению, не переводится с английского: "with great power comes great electricity bill".
В отличие от разработчика, например, на Си, код которого запускается на клиентском компьютере, PHP-код всегда выполняется на сервере.
В этом есть свои плюсы: не всегда надо следить за максимальной совместимостью, выполнение кода всегда происходит подконтрольно, все ошибки видны - не приходится просить у пользователя прислать диагностические данные.
В то же время, главный минус - масштабирование нагрузки происходит исключительно за счет собственного железа. Там, где код сишника выполняется на секунду дольше на ста тысячах пользовательских компьютеров, потеря 28 часов незаметна. Приложение съело лишние 10 мегабайт памяти? Плевать, никто не заметит.
Ради интереса я полюбопытствовал, сколько памяти занимает прямо сейчас на моем компьютере мессенджер Telegram, работающий в фоновом режиме. В этом режиме, когда единственная его задача - вовремя получить сообщение, он занимает 736 Мб. Меня это не беспокоит, потому что этот процесс в моей системе один, и свободной памяти в системе много.
Теперь представим на минуту, что обработка какого-то запроса на PHP занимает 0.1 сек. и требует 100 Мб памяти.
Грубо прикинем, сколько памяти будет занято при обработке тысячи таких запросов в секунду: 0.1 сек/запрос * 100 Мб * 1000 запросов/сек = 10 000 Мб. Здесь мы предполагаем, что обработка процесса откусывает 100 Мб, нужные для работы, и освобождает их сразу после окончания работы.
При стандартной нагрузке наш сервер потребляет около 10 Гб памяти. Что произойдет, если мы "оптимизируем" наш код, и он начнет выполняться медленнее на 0.1 сек? Правильно, общее потребление памяти вырастет в два раза! Цена задержки всего на одну десятую секунды - дополнительные 10 Гб памяти, которая на сервере конечна.
Если же мы могучи и сильны, и затормозим выполнение запроса до одной секунды, с большой вероятностью ресурсов сервера не хватит.
Это не так сложно, потому что процессы выполняются в единой среде, начинают мешать друг другу, становятся в очереди на подключение к сервисам, от этого начинают потреблять еще больше ресурсов - и так далее, пока что-нибудь не приляжет.
Собственно, все вот эти облачные инфраструктуры и появились как ответ на желание масштабировать нагрузку, которую не в состоянии вынести один сервер. Ведь новый сервер устанавливать долго, а виртуальную машину можно создать за несколько секунд.
Итак, в чем же отличие Си-колдуна от PHP-боярина?
Там, где Си-колдун расходует чужие ресурсы, PHP-боярин тратит свои, и на собственной шкуре чувствует, когда что-то сделано недостаточно быстро или недостаточно качественно.
PHP-боярин, как человек, имеющий "свою шкуру на кону", более заинтересован сделать все хорошо. Ведь с большим траффиком приходит и большая нагрузка на сервер.
И если в команде нет боярина, модные бородатые DevOps'ы с радостью создадут тысячу виртуальных машин для обработки запросов.
А счет придет вам, и будет уже не так радостно.