EDIT: Я неправильно прочитав оригінальний пост. 168 модулів - це багато, а від 300 до 700 мс SQL запитів величезна кількість . Чим більше модулів ви будете використовувати, тим більше запитів вони будуть, як тільки модулі виконають.
Використовуйте агресивне кешування, поки можете, кешуйте все, якщо цього недостатньо, спробуйте зворотний кеш-проксі. Використання CDN для файлів може значно покращити все. Зворотний кеш-проксі також може допомогти вам, видаливши деякі автентичні файли cookie, коли потрапляє на сторінки, які не потребують його (тоді ядро подумає, що користувач анонімний для них і максимально збільшить кешування).
Динамізм ядра Drupal змушує весь світанок повільно, як тільки у вас одночасно взаємодіє занадто багато модулів.
Я б сказав, наприклад, якщо ви використовуєте багато модулів, які завантажують дані в час kuk_node_load () замість полів, це зробить багато запитів, тоді як використання поля забезпечить ефективність кешування.
Візуалізація також може зайняти багато часу, drupal_render () (API рендеринга колись називається) - це приємний фрагмент API (дійсно корисний), але також трохи повільний. Перехід на PDO (D7) та повний DBTNG (що, до речі, чудово), також додає затримку, що не викликає негативності.
Однак, ядро само по собі є досить швидким (але воно робить занадто багато SQL запитів, навіть майже нічого не встановлене), слабко закодовані модулі часто є вузьким місцем.
APC може розділити час виконання на 2 або 3, залежно від коду, який працює. якщо ви добре налаштуєте його (увімкніть усі оптимізації APC, офіційний посібник APC добре написаний і буде керувати вами).
Якщо ви знаходитесь в коробці з повільною файловою системою (мережева файлова система або повільний жорсткий диск), це може спричинити видимий вплив на час виконання. Drupal створений з безлічі невеликих файлів, що змушує PHP робити введення-виведення на FS кожного разу, коли він завантажує один з них (APC також дуже допомагає для цього).
Неправильно налаштована СУБД також може бути досить потворним вузьким місцем, якщо ви використовуєте MySQL, подумайте про точну настройку. Якщо ви перебуваєте на спільному хостингу, якщо це не специфічний для Drupal (або готовий) стек СУБД і PHP, можливо, буде неправильно налаштований або не налаштований, що може призвести до дійсно повільних сайтів.
Не забудьте активувати всі кеші. Якщо ваш сайт не має автентифікації, орієнтований на користувача, активуйте кешування агресивної сторінки (це дійсно дивовижно).
Чим більше у вас буде блоків, тим повніші сторінки будуть повільними, блоки модулів перегляду будуть вузьким світом (залежно від використовуваних плагінів Views, блок OG може бути справжнім болем), якщо ви не обмежите їх видимість на основі сторінки або з користувацьким кодом PHP (будь-який інший блок також, завжди встановлюйте видимість свого блоку вручну, значно допомагає фреймворку, уникаючи спроби візуалізувати порожні блоки).
Уникайте модулів, у яких використовується запуск_ініт (), гак_ініт () запускається на кожній сторінці, навіть якщо ви отримаєте 403 або 404, що сповільнює все (це навіть сповільнює час створення файлів imagecache | | стилю, і 404 помилок у файлах буде світанок повільний, щоб повідомити, що файл не існує).
