Я не могу полагать, что никто уже не упомянул это: Модуляризация и Абстракция. Если Вы думаете, что Ваш сайт оказывается перед необходимостью расти до большого количества машин, Вы должны дизайн он так, он может! Это означает, что глупым вещам нравится, не предполагают, что база данных находится на localhost. Это также означает вещи, которые будут беспокойством сначала, как запись уровня абстракции базы данных (как PDO, но намного намного легче потому что это только делает то, что Вам нужен он, чтобы сделать).

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

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

Изучите mod_cache, выходной кэш для веб-сервера Apache, подобного кэшированию вывода в ASP.NET.

Да, я вижу, что это все еще экспериментально, но это будет окончательным когда-нибудь.

Я не вижу, что я переключаюсь от MySQL в ближайшее время - таким образом, я предполагаю, что мне не нужны возможности абстракции PDO. Спасибо за те статьи DavidM они помогли мне много.

Gary

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

я смотрю по PDO в данный момент, и похоже, что Вы правы - однако я знаю, что MySQL разрабатывает расширение MySQLd для PHP - я думаю для следования за или MySQL или за MySQLi - что Вы думаете об этом?

Ryan, Eric, tj9991

спасибо за совет относительно кэширующихся расширений PHP - Вы могли объяснить причины использования того по другому? Я услышал большие вещи о memcached через IRC, но никогда не слышал о APC - каковы Ваши мнения о них? Я предполагаю, что использование нескольких кэширующихся систем является довольно противоэффективным.

я буду определенно разбираться в некоторых профильных тестерах - большое спасибо за Ваши рекомендации на тех.

Много хороших ответов уже было дано, но я хотел бы указать на Вас на альтернативный кэш кода операции, названный XCache. Это создается lighty участником.

кроме того, если Вам, возможно, понадобится выравнивание нагрузки Ваш сервер базы данных в будущем, , MySQL Proxy мог бы очень хорошо помочь Вам достигнуть этого.

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

Верный pdo хорош, но там имеет [приблизительно 112] противоречие о, это - производительность по сравнению с mysql и mysqli, хотя это кажется фиксированным теперь.

Плюс, если производительность действительно необходима, готовятся к (собственный mysql) драйвер MysqLnd в PHP 5.3, кто будет намного более тесно интегрирован с php с лучшей производительностью и улучшенным использованием памяти (и статистика для настройки производительности).

Кэш-память хороша при кластеризации серверов (и подобная YouTube загрузка), но я испытал бы APC сначала также.

PDO является также очень медленным, и его API является довольно сложным. Никто в их нормальном уме не должен использовать его, если мобильность не является беспокойством. И давайте столкнемся с ним в 99% всех веб-приложений, которые это не. Вы просто придерживаетесь MySQL или PostrgreSQL, или независимо от того, что это - Вы, работают с.

Что касается вопроса PHP и что принять во внимание. Я думаю, что преждевременная оптимизация является корнем всего зла.;) Получают Ваше приложение, сделанное сначала, пытаются содержать его в чистоте когда дело доходит до программирования, сделать немного документации и модульных тестов записи. Со всеми вышеупомянутыми у Вас не будет проблем, осуществляющих рефакторинг код, когда время настанет. Но сначала Вы хотите быть сделанными и выставить его, чтобы видеть, как люди реагируют на него.

спасибо за совет относительно кэширующихся расширений PHP - Вы могли объяснить причины использования того по другому? Я услышал большие вещи о memcached через IRC, но никогда не слышал о APC - каковы Ваши мнения о них? Я предполагаю, что использование нескольких кэширующихся систем является довольно противоэффективным.

На самом деле, многие действительно используют APC и memcached вместе ...

Если это имеет значение кэширование является ГРЯЗЬЮ, ПРОСТОЙ в PHP даже без пакета расширения/помощника как memcached.

Все, что необходимо сделать, создают буфер вывода с помощью ob_start().

Создают функцию глобального кэша. Назовите ob_start, передайте функцию как обратный вызов. В функции ищите кэшированную версию страницы. Если существует, служите ему и конец.

, Если это не существует, сценарий продолжит обрабатывать. Когда это достигнет соответствия ob_end (), это вызовет функцию, которую Вы определили. В то время Вы просто получаете содержание буфера вывода, отбрасываете их в файле, сохранили файл и конец.

Добавляют в некотором истечении/сборке "мусора".

И многие люди не понимают, что можно вложить ob_start() / ob_end() вызовы. Таким образом, если Вы уже используете буфер вывода, чтобы, скажем, проанализировать в рекламных объявлениях или сделать подсветку синтаксиса или что бы то ни было, можно просто вложить другой ob_start/ob_end вызов.

Я выполняю веб-сайт с 7-8 миллионами просмотров страницы в месяц. Не ужасно очень, но достаточно, что наш сервер чувствовал загрузку. Решение, которое мы выбрали, было просто: Кэш-память на уровне базы данных. Это решение работает хорошо, если загрузка базы данных является Вашей основной проблемой.

Мы начали использовать Кэш-память для кэширования всех объектов и результатов базы данных, которые наиболее часто использовались. Это действительно работало, но это также представило ошибки (мы, возможно, избежали некоторых из тех, если бы мы были более осторожными).

, Таким образом, мы изменили наш подход. Мы создали обертку базы данных (с теми же самыми методами как наша старая база данных, таким образом, было легко переключиться), и затем мы разделили его на подклассы для обеспечения memcached методов доступа к базе данных.

Теперь все, что необходимо сделать, решают, может ли запрос использовать кэшируемый (и возможно устаревший) результаты или нет. Большинство запросов, выполненных пользователями, теперь выбирается непосредственно от Кэш-памяти. Исключениями являются обновления, и вставляет, который для основного веб-сайта только происходит из-за входа. Эта довольно простая мера уменьшила нашу загрузку сервера приблизительно на 80%.

Профилирование Вашего приложения с чем-то как Xdebug (как рекомендуемый tj9991) определенно будет необходимостью. Это не имеет много смысла просто обойти вещи оптимизации вслепую. Xdebug поможет Вам найти реальные узкие места в своем коде, таким образом, можно будет провести время оптимизации мудро и зафиксировать блоки кода, которые на самом деле вызывают медленные холмы.

при использовании Apache другая утилита, которая может помочь в тестировании, Осада . Это поможет Вам ожидать, как Ваш сервер и приложение будут реагировать на высокие загрузки путем реального проверения его в деле.

Любой вид кэша кода операции для PHP (как APC или один из многих других) поможет много также.

Во-первых, поскольку я думаю, что Knuth заявил, "Преждевременная оптимизация является корнем всего зла". Если Вы не должны заниматься этими проблемами, прямо сейчас тогда не делают, внимание на поставку чего-то, что работает правильно сначала. Однако если оптимизация не может ожидать.

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

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

Распадающиеся базы данных среди серверов и использования своего рода метода выравнивания нагрузки (например, генерируют случайное число между 1 и # избыточные базы данных с необходимыми данными - и используют то число для определения, какой сервер базы данных соединиться с) может также быть отличный способ увеличить эффективность.

Они все удались вполне прилично в прошлом для некоторых, довольно высоко загружают сайты. Надежда это помогает получить Вас, запустила:-)

APC является насущной необходимостью. Мало того, что это делает для большой системы кэширования, но усиление из автокэшируемых файлов PHP является удачей. Что касается нескольких идея базы данных, я не думаю, что Вы вытащили бы много из наличия различных баз данных по тому же серверу. Это может дать Вам что-то вроде усиления в скорости в течение времени запроса, но я сомневаюсь относительно усилий, которые это приложило бы, чтобы развернуть и поддержать код для всех трех при проверке, что они находятся в синхронизации, стоило бы того.

я также настоятельно рекомендую выполнение Xdebug для нахождения узких мест в программе. Это сделало оптимизацию бризом для меня.

Общий

• не пытаются оптимизировать, прежде чем Вы начнете видеть, что реальный мир загружается. Вы могли бы угадать, но если Вы не делаете, Вы потратили впустую свое время.
• Использование jmeter, xdebug или другой инструмент для сравнительного тестирования сайта.
• , Если загрузка начинает быть проблемой, или объект или кэширование данных будут, вероятно, включены, так обычно читать на кэширующихся опциях (memcached, опциях кэширования MySQL)

Код

• Профиль Ваш код так, чтобы Вы знали, где узкое место, и является ли это в коде или базе данных

Базы данных

• Использование MYSQLi, если мобильность к другим базам данных не жизненно важна, PDO иначе
• , Если сравнительные тесты показывают, что база данных является проблемой, проверьте запросы, прежде чем Вы начнете кэшироваться. Используйте , ОБЪЯСНЯЮТ для наблюдения, где запросы замедляются.
• После того, как запросы оптимизированы, и база данных кэшируется в некотором роде, можно хотеть использовать несколько баз данных. Или тиражирование в несколько серверов или sharding (разделяющий данные по нескольким базам данных/серверам) может быть соответствующим, в зависимости от данных, запросов и вида поведения чтения-записи.

Кэширование

• Много записей делалось на кэширующемся коде, объектах и данных. Ищите статьи о APC, Оптимизатор Зенда , memcached, QuickCache, JPCache. Сделайте часть этого, прежде чем Вы действительно должны будете, и Вы будете менее обеспокоены начинанием неоптимизированного.
• APC и Оптимизатор Зенда являются кэшами кода операции, они ускоряют код PHP путем предотвращения перепарсинга и перекомпиляции кода. Вообще простой установить, стоящий выполнения рано.
• Memcached является универсальным кэшем, который можно использовать для запросов кэша, функций PHP или объектов или всех страниц. Код должен быть конкретно записан для использования его, который может быть включенным процессом, при отсутствии центральных точек для обработки создания, обновления и удаления кэшируемых объектов.
• QuickCache и JPCache являются кэшами файла, в других отношениях подобными Memcached. Фундаментальное понятие просто, но также и требует кода и легче с центральными точками создания, обновления и удаления.

Разное

• Рассматривают альтернативные веб-серверы для высокой загрузки. Серверы как [1 110] lighthttp и nginx может обработать большие объемы торговли намного меньшей памятью, чем [1 112] Apache, если можно пожертвовать питанием и гибкостью Apache (или если Вам просто не нужны те вещи, которые часто, Вы не делаете).
• Помнят, что аппаратные средства являются удивительно дешевыми в эти дни, так убедиться стоить усилия оптимизировать большой блок кода по сравнению с, "давайте купим сервер монстра".
• Рассматривают добавление "MySQL" и "масштабирование" тегов к этому вопросу

Ре: PDO / MySQLi / MySQLND

gary

, который Вы не можете только сказать, "не использует MySQLi", поскольку у них есть различные цели. PDO почти похож на уровень абстракции (хотя это не на самом деле), и разработан, чтобы облегчить использовать несколько продуктов базы данных, тогда как MySQLi характерен для соединений MySQL. Неправильно сказать, что PDO является современным слоем доступа в контексте сравнения его к MySQLi, потому что Ваш оператор подразумевает, что прогрессия была mysql-> mysqli-> PDO, который не имеет место.

выбор между MySQLi и PDO прост - если необходимо поддерживать несколько продуктов базы данных тогда, Вы используете PDO. Если Вы просто используете MySQL тогда, можно выбрать между PDO и MySQLi.

Итак, почему Вы выбрали бы MySQLi over PDO? Посмотрите ниже...

@ross

Вы корректны о MySQLnd, который является новейшей библиотекой уровня базового языка MySQL, однако это не замена для MySQLi. MySQLi (как с PDO) остается способом, которым Вы взаимодействовали бы с MySQL через свой код PHP. Оба из них используют libmysql в качестве клиента C позади кода PHP. Проблема состоит в том, что libmysql за пределами базового механизма PHP, и это - то, где mysqlnd входит, т.е. это - Собственный Драйвер, который использует базовые внутренности PHP для увеличения эффективности, конкретно где использование памяти затронуто.

MySQLnd разрабатывается MySQL самостоятельно и недавно приземлился на ответвление PHP 5.3, которое находится в тестировании RC, готовом к выпуску позже в этом году. Вы тогда будете в состоянии использовать MySQLnd с MySQLi..., но не с PDO. Это даст MySQLi повышение производительности во многих областях (не все) и сделает его лучшим выбором для взаимодействия MySQL, если Вам не будет нужна абстракция как возможности PDO.

Однако MySQLnd теперь доступен в PHP 5.3 для PDO и таким образом, можно получить преимущества улучшений производительности от ND в PDO, однако, PDO является все еще универсальным слоем базы данных и так будет вряд ли, чтобы быть в состоянии извлечь выгоду так из улучшений в ND, как MySQLi может .

Некоторые полезные сравнительные тесты могут быть найдены здесь , хотя они с 2006. Также необходимо знать о вещах как эта опция .

, Там много соображений, которые должны быть приняты во внимание при решении между MySQLi и PDO. Это действительность, это не будет иметь значение, пока Вы не добираетесь до смехотворно высоких чисел запроса и в этом случае, имеет больше смысла использовать расширение, которое было специально предназначено для MySQL, а не того, какие вещи кратких обзоров и, оказывается, обеспечивает драйверу MySQL.

Это не простой вопрос, из которого является лучшим, потому что у каждого есть преимущества и недостатки. Необходимо прочитать ссылки, которые я предоставил и придумал собственное решение, затем тестирую его и узнаю. Я использовал PDO в прошлых проектах, и это - хорошее расширение, но моим выбором для чистой производительности был бы MySQLi с новой скомпилированной опцией MySQLND (когда PHP 5.3 выпущен).

Я работал над несколькими сайтами, которые поддержали миллионы/хиты/месяц PHP & MySQL. Вот некоторые основы:

1. Кэш, кэш, кэш. Кэширование является одним из самых простых и самых эффективных способов уменьшить нагрузку на Ваш веб-сервер и базу данных. Содержание страницы кэша, запросы, дорогое вычисление, что-либо, что является связанным вводом-выводом. Кэш-память является очень простой и эффективной.
2. Использование несколько серверов, как только Вы истрачены. У Вас может быть несколько веб-серверов и несколько серверов баз данных (с репликацией).
3. Уменьшают полный # запроса к Вашим веб-серверам. Это влечет за собой кэширование, JS, CSS и использование изображений истекают заголовки. Можно также переместить статическое содержание в CDN, который ускорит опыт пользователя.
4. Мера & сравнительный тест. Выполненный Nagios на Ваших производственных машинах и нагрузочный тест на Вашем dev/qa сервере. Необходимо знать, когда сервер загорится так, можно предотвратить его.

я рекомендовал бы читать Создающие Масштабируемые Веб-сайты , это было записано одним из инженеров Flickr и является большой ссылкой.

Выезд мое сообщение в блоге о масштабируемости также, это имеет много ссылок на представления о масштабировании с несколькими языками и платформами: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

Я - ведущий разработчик на сайте с по 15M пользователи. У нас было очень мало масштабирующихся проблем, потому что мы запланировали его РАНО и масштабируемый глубокомысленно. Вот некоторые стратегии, которые я могу предложить на основе своего опыта.

СХЕМА Прежде всего, денормализуйте свои схемы. Это означает, что, а не иметь несколько реляционных таблиц, необходимо вместо этого решить иметь одну большую таблицу. В целом соединения являются тратой драгоценных ресурсов DB, потому что выполнение нескольких готовится и дисковый ввод-вывод записей сопоставления. Избегайте их, когда Вы будете мочь.

компромисс здесь - то, что Вы будете хранить/вытягивать избыточные данные, но это приемлемо, потому что пропускная способность данных и внутриклетки является очень дешевой (большие диски), тогда как несколько готовятся, ввод-вывод более дорогие порядки величины (больше серверов).

ИНДЕКСАЦИЯ Удостоверяется, что Ваши запросы используют по крайней мере один индекс. Остерегайтесь, хотя, которого индексы будут стоить Вам, если Вы запишете или часто обновлять. Существуют некоторые экспериментальные приемы для предотвращения этого.

можно попытаться добавить дополнительные столбцы, которые не индексируются, которые идут параллельно столбцам, которые индексируются. Тогда у Вас может быть офлайновый процесс, который пишет неиндексированные столбцы по индексированным столбцам в пакетах. Таким образом, можно управлять лучше, когда MySQL должен будет повторно вычислить индекс.

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

КЭШИРОВАНИЕ я настоятельно рекомендую Memcached. Это было доказано крупнейшими плеерами на стеке PHP (Facebook) и очень гибко. Существует два метода к выполнению этого, каждый кэшируется в Вашем уровне DB, другой кэшируется в Вашем слое бизнес-логики.

параметр слоя DB потребовал бы кэширования результата запросов, полученных от DB. Можно хешировать SQL-запрос с помощью md5 () и использование что как ключ поиска прежде, чем идти в базу данных. Позитивный аспект к этому - то, что довольно легко реализовать. Оборотная сторона (в зависимости от реализации) - то, что Вы теряете гибкость, потому что Вы рассматриваете все кэширование того же относительно истечения кэша.

В магазине я работаю в, мы используем бизнес-кэширование слоя, что означает, что каждый реальный класс в нашей системе управляет своей собственной схемой кэширования и тайм-аутами кэша. Это работало вполне прилично на нас, но знать, что объекты, полученные от DB, не могут совпасть с объектами от кэша, таким образом, необходимо будет обновить кэш и DB вместе.

репликация SHARDING ДАННЫХ только получает Вас до сих пор. Раньше, чем Вы ожидают, Ваши записи станут узким местом. Для компенсации удостоверьтесь, что поддерживали данные sharding рано как возможные. Вы, вероятно, захотите застрелиться позже, если Вы не сделаете.

довольно просто реализовать. В основном Вы хотите разделить ключевые полномочия от хранения данных. Используйте глобальный DB для хранения отображения между первичными ключами и кластерными идентификаторами. Вы запрашиваете это отображение, чтобы получить кластер, и затем запросить кластер для получения данных. Можно кэшировать ад из этой операции поиска, которая сделает его незначительной операцией.

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

ОФЛАЙНОВАЯ ОБРАБОТКА не заставляет пользователя ожидать Вашего бэкенда, если они не имеют к. Создайте очередь заданий и переместите любую обработку, что Вы можете офлайн, делание ее отделяется от запроса пользователя.

Это похоже , я был неправ . MySQLi все еще разрабатывается. Но в соответствии со статьей, PDO_MySQL теперь вносится командой MySQL. От статьи:

MySQL Improved Extension - mysqli - является флагманом. Это поддерживает все функции MySQL Server including Charsets, Подготовленных Операторов и Хранимых процедур. Драйвер предлагает гибридный API: можно использовать стиль процедурного или объектно-ориентированного программирования на основе предпочтения. mysqli идет с PHP 5 и. Обратите внимание, что Конец жизни для PHP 4 08.08.2008.

Объекты данных PHP (PDO) уровень абстракции доступа к базе данных. PDO позволяет Вам использовать те же вызовы API различных баз данных. PDO не предлагает степени абстракции SQL. PDO_MYSQL является драйвером MySQL для PDO. PDO_MYSQL идет с PHP 5. С разработчиков MySQL PHP 5.3 активно способствуют ему. Преимущество PDO объединенного API прибывает в цену, что MySQL определенные функции, например, несколько операторов, не полностью поддерживается через объединенный API.

прекратите использовать первый драйвер MySQL для PHP, когда-либо опубликованного: ext/mysql. Начиная с введения MySQL Improved Extension - mysqli - в 2004 с PHP 5 нет никакой причины все еще использовать самый старый драйвер вокруг. ext/mysql не поддерживает Наборы символов, Подготовленные Операторы и Хранимые процедуры. Это ограничено набором функций MySQL 4.0. Обратите внимание, что Расширенная Поддержка MySQL 4.0 заканчивается 31.12.2008. Не ограничивайте себя набором функций такого старого программного обеспечения! Обновите до mysqli, см. также Converting_to_MySQLi. mysql находится в обслуживании только режим с нашей точки зрения.

мне, кажется, что статья склоняется к MySQLi. Я предполагаю, что склоняюсь к PDO. Я действительно как PDO по MySQLi. Это является прямым мне. API намного ближе к другим языкам, в которых я запрограммировал. Интерфейсы БД OO, кажется, работают лучше.

я не столкнулся ни с какими определенными функциями MySQL, которые не были доступны через PDO. Я был бы удивлен, делал ли я когда-нибудь.

Если вы работаете с большими объемами данных, а кеширование их не сокращает, загляните в Sphinx. Мы получили отличные результаты, используя SphinxSearch не только для лучшего поиска текста, но и в качестве замены поиска данных для MySQL при работе с большими таблицами. Если вы используете SphinxSE (плагин MySQL), он превзошел наш прирост производительности, который мы получили от кеширования в несколько раз, и реализация приложения - это просто.

Пункты, сделанные в отношении кеша, точны; это наименее сложная и самая важная часть создания эффективного приложения. Я хотел бы добавить, что, хотя memcached великолепен, APC примерно в пять раз быстрее, если ваше приложение находится на одном сервере.

В сообщении «Сравнение производительности кэша» в блоге о производительности MySQL есть несколько интересных тестов по этому вопросу - http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/ .

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

Производительность не имеет значения, если сайт недоступен. А для доступности вам необходимо горизонтальное масштабирование. Минимум, который вам может сойти с рук, - это 2 сервера, на обоих запущены apache, php и mysql. Настройте один СУБД в качестве подчиненного устройства для другого. Выполняйте все записи на главном сервере и все чтения в локальной базе данных (что бы это ни было) - если по какой-то причине вам не нужно считывать данные, которые вы только что прочитали. (используйте мастер). Убедитесь, что у вас есть оборудование для автоматического продвижения раба и ограждения хозяина. Используйте циклический DNS для адресов веб-серверов, чтобы обеспечить большее соответствие подчиненному узлу.

Разделение данных по разным узлам базы данных на этом этапе - очень плохая идея, однако вы можете рассмотреть возможность разделения их по разным базам данных на одном сервере (что упростит разделение между узлами, когда вы обгоните facebook).

Убедитесь, что у вас есть инструменты мониторинга и анализа данных для измерения производительности ваших сайтов и выявления узких мест. Большинство проблем с производительностью можно исправить, написав лучший SQL / исправив схему базы данных.

Хранение кэша шаблонов в базе данных - глупая идея - база данных должна быть центральным общим хранилищем для структурированных данных. Храните кеш шаблона в локальной файловой системе ваших веб-серверов - он будет доступен быстрее и не замедлит доступ к вашей базе данных.

Используйте кеш-код операции.

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

Нажимайте на клиента как можно больше кэширования.

Используйте mod_gzip, чтобы сжать все, что вы можете.

С.

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

В целом, Простота - это быстро. Шаблоны замедляют работу. Базы данных замедляют работу. Сложные библиотеки замедляют работу. Наложение шаблонов друг на друга, получение их из баз данных и разбор их в сложной библиотеке --> временные задержки умножаются друг на друга.

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

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