Я не раз сталкивался с подобной проблемой, когда люди приходят и просят помочь в решении проблем с распределением нагрузки, когда аудитория их сайтов внезапно увеличивается.
Ну и самая трудоемкая часть этой проблемы — это самописные CMS-подобные системы, которые иногда приходится полностью переписывать.
Я не буду вдаваться в подробности распределения нагрузки, а распишу лишь основные правила, если их соблюдать, ваша CMS легко масштабируется.
Правило №1 : все исполняемые скрипты должны иметь расширение .
php но только .
php , даже включения
не будет проблем при работе на другом веб-сервере, а также в целях безопасности.Правило №2 : используйте функции по минимуму .
htaccess и особенно никаких параметров типа: RewriteRule ^(.
+)$ index.phpЭpath=$1
потому что другой веб-сервер не поддерживает .Правило №3 : не злоупотребляйте mod_rewrite -ом, не используйте виртуальные пути для статических файлов (jpg, gif, css, js и т.д.)htaccess , а в конфиге не всегда получится настроить одинаково и это займет больше времени
статика должна быть статикойПравило №4 : использовать полные пути при работе с файлами и хранить пути к папкам в конфиге
потому что статика обычно переносится на другой серверПравило №5 : не бойтесь кэшировать контент в файлах, статический HTML обрабатывается быстрее, чем PHP-скрипт, открывающий кешированный файл на диске.
не забывайте, кешировать можно не только html, но и xml и т.д.Правило №6 : при отрисовке страницы не должно быть лишних SQL-запросов, вставляющих записи в таблицу
передавать статистику в Google Analytics и журналы веб-сервераПравило №7 : чем проще SQL-запрос, тем выше его производительность.
сопоставление таблиц — это хорошо, но неэффективно, особенно для больших объемовПравило №8 : используйте минимум индексов, по возможности избавьтесь от индексов в текстовых полях
чем больше индексов, тем дольше время записи и не забывайте, что таблица во время записи блокируетсяПравило №9 : Не используйте поля полнотекстового поиска в основных таблицах.
используйте отдельную таблицу для поискаПравило №10 : обеспечить возможность системным модулям использовать разные серверы баз данных, а также выполнять разные типы операций (чтение/запись и удаление).
понадобится при использовании нескольких серверов MySQL (Master-Slave) * хотя достаточно правильно использовать ООП, а затем добавить эти опции, изменив только класс работы с БДПравило №11 : PHP, в конце концов, является объектно-ориентированным языком, поэтому не обращайтесь напрямую к переменным сервера ($_SERVER, $_POST, $_GET, $_SESSION) — используйте объекты
Некоторые переменные в других веб-серверах имеют другие имена, а некоторые вообще не существуют и их придется вычислять или придумывать (печально обстоят дела с сессиями)Пост написан подразумевая, что разработчик знает, что такое оптимизация кода и запросов: - что лучшая оптимизация операции - это ее исключить, лучше всего, если сервер вообще не получит запрос, если он его получит, то пусть оно должно быть статическим, если оно динамическое, то оно не трогает базу данных, а если и коснулось базы, то не трогало диск.
Ну вот и всё главное, что сейчас пришло в голову.
Если эта тема будет интересна, я дополню список еще и подробно разберу некоторые вещи в зависимости от ваших вопросов и комментариев.
Теги: #CMS #php #Распределенные системы #распределение нагрузки #правила #php
-
Потеряли Данные В Облаках?
19 Oct, 24 -
Ностальгия По Wow
19 Oct, 24 -
Обзор Курсов Веб-Разработки
19 Oct, 24 -
Сисадмин Разработчику 1С
19 Oct, 24
