Является ли использование PHP с полнофункциональным фреймворком для проекта с высокой нагрузкой плохой идеей?

Question

Является ли использование PHP с полнофункциональным фреймворком для проекта с высокой нагрузкой плохой идеей?

0

Я знаю, что PHP-код скомпилирован в байт-код и повторно выполняется при каждом запуске (т.е. На каждом запросе страницы). Поэтому двигатель должен переопределять все используемые классы, функции, переменные и т.д. По каждому запросу.

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

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

С другой стороны, приложение, основанное на таких двигателях, как NodeJS или Ruby, скомпилировано и загружено только один раз во время запуска. Поэтому я предполагаю, что они должны обладать лучшей масштабируемостью, чем PHP.

Но PHP настолько популярен, и даже Facebook использует его. Поэтому мне интересно, какой правильный выбор для веб-сайта, который может столкнуться с большой нагрузкой? Является ли использование PHP с полным стеком для этой цели плохая идея?

Andrew Starostin 24 фев. 2015, в 17:45

Источник

2

Если это «плохая идея», то чертовски много очень успешных компаний пошли с этой «плохой идеей», и она сработала для них, так может ли она действительно быть такой «плохой идеей»? Воображение, поддерживаемое большим количеством FUD, не является объективным способом оценки масштабируемости приложений ... но хорошо разработанные приложения PHP будут хорошо масштабироваться (я работал над приложениями, которые получают несколько тысяч обращений в секунду, со средним временем отклика 300 мс) и плохо разработанными приложениями Ruby или NodeJS не будут хорошо масштабироваться
Mark Baker 24 фев. 2015, в 16:26

Теги:

php

performance

ruby

high-load

1 ответ

Ещё вопросы

Если это «плохая идея», то чертовски много очень успешных компаний пошли с этой «плохой идеей», и она сработала для них, так может ли она действительно быть такой «плохой идеей»? Воображение, поддерживаемое большим количеством FUD, не является объективным способом оценки масштабируемости приложений ... но хорошо разработанные приложения PHP будут хорошо масштабироваться (я работал над приложениями, которые получают несколько тысяч обращений в секунду, со средним временем отклика 300 мс) и плохо разработанными приложениями Ruby или NodeJS не будут хорошо масштабироваться

ceejayoz · Accepted Answer · 2015-02-24T15-19-00.000Z

Я знаю, что PHP-код скомпилирован в байт-код и повторно выполняется при каждом запуске (т.е. На каждом запросе страницы). Поэтому двигатель должен переопределять все используемые классы, функции, переменные и т.д. По каждому запросу.

Начиная с PHP 5.5, кеш-код операции используется по умолчанию. До этого можно было использовать APC. Вы также можете использовать что-то вроде HHVM для дальнейшего повышения производительности с помощью JIT-компиляции (PHP 7 будет включать в себя аналогичные улучшения).

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

Laravel (я не могу говорить для CakePHP) загружает только классы, когда они используются - большинство ваших классов никогда не будут загружаться в среднем запросе. Большая паранойя об использовании больших рамок, таких как Symfony/Laravel, - это просто паранойя.

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

Кэширование кода и каркасные кэши (файлы, Redis и т.д.) Предлагают огромные преимущества, которые вы довольно кавалеризируете здесь. Да, код должен быть выполнен для каждого запроса (хотя что-то вроде Varnish может уменьшить даже это), но такая вещь верна для любого языка и любой структуры.

HHVM - это то, что Facebook использует за кулисами, чтобы сделать их PHP масштабируемым. Они являются основными участниками проекта, поэтому он уделяет большое внимание производительности. Как и большинство вещей в нашей сфере, это сводится к конкретному сценарию использования, требованиям и предпочтениям / навыкам.