Советы для разработчиков CMS и фреймворков на PHP

Уже не раз сталкиваюсь с подобной проблемой, когда люди приходят и просят помочь в решении проблем распределения нагрузки при внезапном возрастании аудитории их сайтов. Ну и самое трудоемкое в данной проблеме — это самописные CMS-подобные системы, которые иногда приходиться переписывать полностью.

Я не буду вдаваться в подробности распределения нагрузки, а отпишу лишь основные правила при соблюдении которых Ваша CMS будет легко масштабироваться.


Правило #1: все исполняемые скрипты должны иметь расширение .php и только .php, даже инклюды

не будет проблем при запуске на другом веб-сервере, а также для безопасности.

Правило #2: по минимуму использовать функции .htaccess и тем более никаких параметров типа:
RewriteRule ^(.+)$ index.php?path=$1

т.к. другой веб-сервер не поддерживает .htaccess, а в конфиге не всегда удастся настроить так же и отнимет больше времени

Правило #3: не злоупотреблять mod_rewrite-ом, не использовать виртуальных путей для статических файлов (jpg, gif, css, js и т.д.)

статика должна быть статикой

Правило #4: использовать полные пути при работе с файлами и хранить пути к папкам в конфиге

т.к. статику обычно переносят на другой сервер

Правило #5: не бойтесь кэшировать контент в файлы, статическая html-ка отдается быстрее чем php-скрипт открывающий файл с кэшем на диске.

не забывайте, можно кэшировать не только html но и xml и т.п.

Правило #6: при рендере страницы не должно быть лишних SQL-запросов вставляющих записи в таблицу

статистику отдайте Google Analytics и логам веб-сервера

Правило #7: чем проще SQL запрос, тем больше его скорость работы

сопоставление таблиц — это красиво, но не эффективно, особенно при больших объемах

Правило #8: использовать минимум индексов, избавиться по возможности от индексов в текстовых полях

чем больше индексов, тем больше время записи и не забывайте, что во время записи лочится таблица

Правило #9: не использовать поля с полнотекстовым поиском в основных таблицах

для поиска используйте отдельную таблицу

Правило #10: предусмотреть возможность модулям системы использовать разные сервера БД и так же для разных типов операций (чтения/записи и удаления)

понадобится при использовании нескольких серверов MySQL (Master-Slave)
* хотя достаточно грамотно использовать ООП и потом добавить эти опции изменив только класс для работы с БД

Правило #11: PHP, все-таки, объектно-ориентированный язык, поэтому обращайтесь не напрямую к серверным переменным ($_SERVER, $_POST, $_GET, $_SESSION) — используйте объекты

Некоторые переменные в других веб-серверах имеют другие имена, а некоторых вовсе нет и их придется вычислять или придумывать (печально дело обстоит с сессиях)

Пост писал подразумевая, что разработчик знает, что такое оптимизация кода и запросов: — что лучшая оптимизация операции ее исключение, лучше всего если сервер вообще не получит запрос, если получит то пусть он будет статичный, если динамичный, то не трогал базу, а если и трогал базу, то не трогал диск.

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