Масштабирование PHP-приложений

Question

У меня есть существующий сайт PHP, который написан по-старому.

Каждая страница имеет одинаковый шаблон

<?php
require_once("config.php");
//Some code
require_once("header.php");
?>
Some HTML and PHP code mixture
<?php
require_once("footer.php");
?>

Где все соединения БД, данные сеанса, языковые файлы инициируются в файле "config.php". И каждый доступ к БД осуществляется с mysql_query вызов,

Никакого ООП, чего бы то ни было, чисто процедурного программирования.

Как бы вы оптимизировали эту структуру кода, чтобы повысить производительность и сделать этот веб-сайт достаточно надежным для обработки большого трафика?

Answer 1

Как бы вы оптимизировали эту структуру кода, чтобы повысить производительность и сделать этот веб-сайт достаточно надежным для обработки большого трафика?

Структура, которую вы нам показали, имеет очень мало возможностей для оптимизации. Делая его объектно-ориентированным, он будет медленнее, чем сейчас. Обратите внимание, что код во включенных файлах может значительно выиграть от различных изменений.

Здесь всего 3 строки кода. Так что не так много возможностей для тюнинга. Конструкции _once добавляют (крошечные) накладные расходы, как и использование require, а не include - но это очень небольшое количество по сравнению с тем, что может происходить в коде, который вы нам не показывали.

Где все соединения БД, данные сеанса, языковые файлы инициируются в файле "config.php"

Опять же, существует незначительная экономия за счет задержки доступа к внешним ресурсам до тех пор, пока они не потребуются (и немедленного отказа от доступа, когда они больше не требуются), но это не является процедурным вопросом в сравнении с OO.

Почему ОО будет медленнее?

Здесь маршрутизация запросов осуществляется через веб-сервер - веб-серверы действительно хороши в этом и обычно очень, очень эффективны. Альтернативный подход с использованием фронтом-контроллера дает некоторые возможности для применения шаблонов в более управляемом способе и для применения поздних заплаток содержания (хотя это спорно, если это хорошая идея). Но использование шаблона фронт-контроллера не является обязательным требованием для ОО.

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

Переопределение и декорирование добавляет дополнительные издержки абстракции и обработки к вызову преобразований данных.

каждый доступ к БД осуществляется с помощью вызова mysql_query

Здесь есть несколько частей. Да, расширение mysql_ устарело, и вы должны стремиться перенести его в качестве приоритета (извините, но я не могу рекомендовать какие-либо хорошие переходы вперед / назад), однако это в основном быстрее, чем движок mysqlnd - последний имеет определенную производительность преимущество с большими наборами данных / большим объемом благодаря уменьшенной загрузке памяти.

Похоже, вы убеждены, что с процедурным программированием что-то не так в отношении производительности и масштаба. Нет ничего более далекого от правды. G-Wan, Apache httpd, Varnish, ATS, ядро ​​Linux написаны на C, а не на C++.

Если вы хотите улучшить производительность и масштабируемость, то вы сейчас находитесь не в том месте. И единственный способ добиться значительных успехов на дорогах - это профилировать ваш код под соответствующие уровни нагрузки.

Answer 2

Если вы действительно не хотите менять свою структуру (ООП и mysql_*... и даже на самом деле), вы должны внедрить систему кеша, чтобы избежать генерации контента каждый раз. Если у вас есть данные, которые не часто меняются (например, запись в блоге, новости или профиль участника), вы можете создать кеш на 5 минут, чтобы облегчить использование SQL. Google может помочь вам в этом.

Существует также множество веб-методов для оптимизации загрузки страниц: используйте CDN для загрузки статических ресурсов, кэш Varnish...

С самим PHP, есть также несколько методов, но об этом есть много постов в блоге, просто посмотрите здесь, например:) Например:

• Избегайте регулярных выражений, если это возможно
• Если вам это нужно, инициализируйте переменную: в 10 раз медленнее увеличивать / уменьшать неинициализированную переменную (кстати, это ужасно)
• Не вызывать функции в for объявление, вместо этого сделайте временную переменную
• и т.п.

Не стесняйтесь тестировать, проведите несколько тестов с JMeter, чтобы смоделировать пул соединений и посмотреть, какая страница медленная, а какую следует оптимизировать в первую очередь.