EDIT: J'ai mal lu le message d'origine. 168 modules, c'est beaucoup, et 300 à 700 ms de requêtes SQL, c'est énorme . Plus vous utiliserez de modules, plus il y aura de requêtes dès que les modules en feront.
Utilisez une mise en cache agressive pendant que vous le pouvez, mettez tout en cache, si cela ne suffit pas, essayez un cache de proxy inverse. L'utilisation d'un CDN pour les fichiers peut grandement améliorer le tout. Un cache de proxy inverse peut également vous aider en supprimant certains cookies d'authentification lorsque vous accédez à des pages qui n'en ont pas besoin (le noyau pensera que l'utilisateur est anonyme pour ceux-ci et maximisera la mise en cache).
Le dynamisme du noyau Drupal ralentit toute l'aube dès que vous avez trop de modules interagissant en même temps.
Je dirais, par exemple, que si vous utilisez beaucoup de modules qui chargent des données au moment de hook_node_load () au lieu d'utiliser des champs, cela fera beaucoup de requêtes tandis que l'utilisation des champs aurait assuré l'efficacité de la mise en cache.
Le rendu peut également prendre beaucoup de temps, drupal_render () (l'API de rendu étant parfois appelée) est un bon morceau d'API (vraiment utile) mais aussi un peu lent. Le passage au PDO (D7) et au DBTNG complet (ce qui est génial au passage) ajoute également une latence non négligeable.
Cela dit, le cœur en lui-même est assez rapide (mais il fait trop de requêtes SQL, même avec presque rien installé), les modules mal codés sont souvent le goulot d'étranglement.
APC peut diviser le temps d'exécution par 2 ou 3, selon le code qui s'exécute. si vous le configurez bien (activez toutes les optimisations APC, le manuel officiel APC est bien écrit et vous guidera).
Si vous êtes sur une boîte avec un système de fichiers lent (système de fichiers réseau ou disque dur lent), cela peut impliquer un impact visible sur le temps d'exécution. Drupal est fait à partir de nombreux petits fichiers, ce qui oblige PHP à faire des E / S sur le FS à chaque fois qu'il en charge un (APC aide également beaucoup pour cela).
Un SGBD mal configuré peut également être un goulot d'étranglement assez laid, si vous utilisez MySQL pensez à faire un réglage fin. Si vous êtes sur un hébergement partagé, s'il n'est pas spécifique à Drupal (ou prêt), la pile SGBD et PHP sera probablement mal configurée ou non réglée, ce qui peut conduire à des sites vraiment lents.
N'oubliez pas d'activer toutes les caches. Si votre site n'est pas orienté utilisateur authentifié, alors activez la mise en cache de page agressive (c'est vraiment incroyable).
Plus vous aurez de blocs, plus les pages complètes seront lentes, les blocs du module Views seront un goulot d'étranglement (selon les plugins Views que vous utilisez, le bloc OG peut être une vraie douleur) si vous ne restreignez pas leur visibilité sur une base par page, ou avec du code PHP personnalisé (tout autre bloc également, définissez toujours votre visibilité de bloc manuellement, aide grandement le framework en évitant de tenter de rendre les blocs vides).
Évitez les modules qui utilisent hook_init (), hook_init () est exécuté sur chaque page, même si vous obtenez un 403 ou un 404, ce qui ralentit tout (cela ralentit même le temps de génération du style imagecache |, et les erreurs 404 sur les fichiers seraient aube lente juste pour vous dire que le fichier n'existe pas).
