J'ai un site que j'étudie qui a des problèmes de performances majeurs, en utilisant memcache j'ai pu réduire le nombre de requêtes en nombre et en temps d'exécution total (de 3 secondes à 230 ms) mais le temps d'exécution de la page m'échappe (je suis en regardant les valeurs générées par devel) ma compréhension est que le temps d'exécution de la page = le temps nécessaire à php pour s'exécuter donc j'ai installé APC et je peux voir l'opcode php mis en cache et les statistiques montrant les hits dans le panneau de contrôle APC (apc.php livré avec APC) mais le temps d'exécution de ma page ne diminue pas. Je pense donc que ma question est double:
- Qu'est-ce qui contribue (ralentit mieux) le temps d'exécution des pages? Est-ce juste du temps pour exécuter php?
- Quelles approches dois-je adopter pour réduire le temps d'exécution des pages. J'ai essayé APC mais pas beaucoup d'aide
Le nombre de modules PS utilisés sur ce site est juste énorme (168) mais pour le moment je ne suis pas en mesure de faire cette recommandation, c'est plus comme un incendie dans la situation du trou.
Edit: Sortie de l'exécution de xhprof sur une instance locale (recommandée par mikeytown), cela semble être fou, je pense que les résultats ultérieurs sont dus à la thrashing? diff s'exécute pour la même URL a une différence drastique et son utilisation des ressources est trop importante. Je ne sais pas non plus pourquoi affiche des valeurs qui ne sont pas d'aujourd'hui: | (Je viens d'installer xhprof sur cet ordinateur portable)
la source
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).
la source