РЕДАКТИРОВАТЬ: я неправильно прочитал оригинальный пост. 168 модулей - это много, а от 300 до 700 мс SQL-запросов огромны . Чем больше модулей вы будете использовать, тем больше будет запросов, как только модули выполнят некоторые из них.
Пока вы можете использовать агрессивное кеширование, кешируйте все, если этого недостаточно, попробуйте обратный прокси-кеш. Использование CDN для файлов может значительно улучшить ситуацию. Кэш обратного прокси-сервера также может помочь вам, удалив некоторые файлы cookie авторизации при попадании на страницы, которые ему не нужны (тогда ядро будет думать, что пользователь является анонимным для них, и максимально увеличивает кэширование).
Динамизм ядра Drupal замедляет весь рассвет, как только у вас одновременно работает слишком много модулей.
Например, я бы сказал, что если вы используете много модулей, которые загружают данные во время hook_node_load (), а не используют поля, это сделает много запросов, в то время как использование поля обеспечит эффективность кэширования.
Рендеринг также может занимать много времени, drupal_render () (иногда называется API рендеринга) - хороший кусок API (действительно полезный), но также немного медленный. Переключение на PDO (D7) и полный DBTNG (что, кстати, здорово) также добавляет неустранимую задержку.
Тем не менее, само по себе ядро довольно быстрое (но оно выполняет слишком много SQL-запросов, даже если почти ничего не установлено), плохо кодированные модули часто являются узким местом.
APC может делить время выполнения на 2 или 3, в зависимости от кода, который выполняется. если вы настроите его правильно (включите все оптимизации APC, официальное руководство APC хорошо написано и поможет вам).
Если у вас установлена система с медленной файловой системой (сетевая файловая система или медленный жесткий диск), это может оказать заметное влияние на время выполнения. Drupal сделан из множества маленьких файлов, что заставляет PHP выполнять ввод / вывод на ФС каждый раз, когда он загружает один из них (APC также очень помогает в этом).
Неправильно настроенная СУБД также может быть довольно неприятным узким местом, если вы используете MySQL, подумайте о тонкой настройке. Если вы пользуетесь виртуальным хостингом, если он не предназначен для Drupal (или готов), СУБД и стек PHP, вероятно, будут неправильно настроены или не настроены, что может привести к очень медленным сайтам.
Не забудьте активировать все кэши. Если ваш сайт не аутентифицирован для пользователя, активируйте агрессивное кэширование страниц (это действительно удивительно).
Чем больше у вас будет блоков, тем медленнее будут заполняться страницы, блоки модулей Views станут узким местом для рассвета (в зависимости от используемых вами плагинов Views блок OG может быть очень болезненным), если вы не ограничите их видимость для каждой страницы или с помощью специального PHP-кода (любой другой блок, всегда устанавливая видимость вашего блока вручную, очень помогает фреймворку, избегая попытки рендеринга пустых блоков).
Избегайте модулей, которые используют hook_init (), hook_init () запускается на каждой странице, даже если вы получаете 403 или 404, который замедляет все (это даже замедляет время генерации imagecache | style, и ошибки 404 для файлов будут рассвет медленный, просто чтобы сказать вам, что файл не существует).
