J'ai mis en place un site D7 avec un sous-thème Minelli. En cours de route, j'ai beaucoup expérimenté différents thèmes, différents modules. Quelque part au cours de mon parcours, j'ai développé un problème de performances inhabituel et je ne sais pas vraiment quel thème / module / config l'a causé.

Le problème est que lorsque je visite le site pour la première fois, il faut environ 15 secondes avant que la première page ne s'affiche. Je peux ensuite me déplacer sur le site et il est très réactif. Si je le laisse pendant une heure environ, j'y reviens, la première demande est à nouveau très lente.

J'ai effacé le cache, donc ça ne devrait pas être le problème. De plus, j'ai désactivé les thèmes et les modules que je n'utilise pas. J'ai déplacé le site vers une nouvelle infrastructure mais le problème l'a suivi!

Où vais-je ensuite?

Il y a trois choses que je vérifierais.

Premièrement, si vous êtes sur un site de production et que vous ne modifiez pas les fichiers PHP, assurez-vous qu'APC est activé, dispose de suffisamment de mémoire et possède une longue durée de vie (vous pouvez y aller avec un jour ou ne jamais expirer si vous le souhaitez). Vous pouvez également envisager de définir apc.stat=0. Les documents APC contiennent toutes les informations nécessaires à la définition de la durée de vie. Pour choisir la quantité de mémoire, vous devez placer le fichier apc.php dans un endroit protégé et surveiller l'utilisation de la mémoire et les statistiques de désabonnement. Ajustez la mémoire APC de manière à ce que votre taux d’abandons soit très faible. La lenteur initiale peut être due au fait que APC est plein et en train de se vider (IIRC, APC vide tout le cache lorsqu'il est plein au lieu d'utiliser des stratégies de cache LRU ou plus avancées).

Deuxièmement, assurez-vous que MySQL est réglé correctement. Vous pouvez utiliser mysqltuner pour ajuster la taille de votre tampon. Votre lenteur initiale peut être due au chargement de tables à partir du disque et / ou aux erreurs du cache de requêtes. Bien que pas parfait, mysqltuner vous amène dans la bonne direction.

Troisièmement, assurez-vous d’avoir une véritable stratégie Drupal Cron . Personnellement, je désactiverais automagic cron sur "admin / config / system / cron" et configurerais une crontab pour qu'elle s'exécute tous les soirs. Vous pouvez également essayer Elysia Cron si vous avez vraiment besoin d’un contrôle plus fin. De cette façon, les tâches nécessaires peuvent être exécutées aussi souvent que vous le souhaitez, mais les tâches normales sont exécutées du jour au lendemain. Votre lenteur initiale pourrait provenir de courses cron se produisant toutes les heures. Vous pouvez le confirmer en regardant quand cron s'exécute sur "admin / reports / dblog" et en essayant de faire correspondre votre lenteur.

Ivanhoe123 a probablement raison: Drupal 7 est livré avec l'option 'médiocre homme' activée par défaut. En bref, cela signifie que (de temps en temps) cron est exécuté avant que Drupal ne rende la page, ce qui retarde tout.

Essayez toujours d'utiliser un vrai travail cron sur les sites de production. Pour plus de détails techniques, voir http://drupal.org/cron , ou parlez-en à votre hébergeur.

Pour le désactiver, allez dans admin / config / system / cron et sélectionnez «Jamais».

Le module Devel propose une journalisation de la base de données pour vérifier si vos requêtes sont longues.

Si cela ne vous aide pas, prenez XHProf ou XDebug et trouvez le code coupable. XHProf (un profileur) dessine une belle carte de toutes les fonctions en cours d’exécution sur le serveur et vous indique quelles sont celles qui consomment le plus de temps d’exécution. Par ailleurs, lorsque XDebug (un débogueur) est configuré avec un IDE tel que Eclipse ( voir la vidéo ), il vous permet d’explorer toutes les fonctions en cours d’exécution LIVE. Le profileur vous donnera une idée de ce qui est exécuté. tandis que le débogueur vous montrera pourquoi il est exécuté.

Juste à la saveur de la question, je pense immédiatement à trois (3) choses

• MySQL Storage Engine / CPU
• Base de données en cache
• Verrouillage de table

Moteur de stockage MySQL

Si vous n'utilisez aucune recherche / indexation FULLTEXT, je vous recommande fortement de convertir toutes vos données MyISAM en InnoDB. MyISAM n'est pas conçu pour tirer parti de plusieurs processeurs et de plusieurs cœurs. InnoDB a été considérablement amélioré pour l’utilisation de plusieurs processeurs ainsi que l’hyperthreading en lecture / écriture.

Voici quelques articles que j'ai publiés à ce sujet dans DBA StackExchange et sur ce site en ce qui concerne l'optimisation de MySQL pour InnoDB Performance.

• Sep 20, 2011: Multi cœurs et performances MySQL
• Sep 12, 2011: Possible de faire en sorte que MySQL utilise plus d'un noyau
• Jun 07, 2011: Comment convertir une base de données de MyISAM en InnoDB?
• May 26, 2011: À propos des performances des bases de données à thread unique par rapport aux bases de données multithread
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Base de données en cache

Un autre argument fort pour la conversion de toutes les données MyISAM en InnoDB est la façon dont MySQL met en cache les données / index. Le moteur de stockage MyISAM met uniquement en cache les index. InnoDB met en cache les données et les index . À la lumière de cela, vous pouvez allouer suffisamment de mémoire pour que le pool de mémoire tampon InnoDB puisse prendre en charge l’un des éléments suivants (le plus petit des deux).

• Toutes les données et tous les index InnoDB (Idéal si vous disposez également de suffisamment de RAM pour le système d'exploitation; élimine les retards ultérieurs)
• 75% de la RAM installée (si vous avez plus de données / index InnoDB que de RAM, minimisez les retards)

Si vous utilisez MySQL 5.1, vous pouvez définir innodb_max_dirty_pages_pct = 0. Cela augmentera légèrement les E / S du disque, mais le pool de mémoire tampon InnoDB sera suffisamment effacé pour permettre aux anciennes pages de données et d'index de tourner sans surtensions d'E / S de disque. Le plug-in InnoDB de MySQL 5.5 et MySQL 5.1 n’a pas besoin de cet ajustement car il dispose d’un meilleur mécanisme de vidage du pool de mémoire tampon.

Si utiliser InnoDB est hors de question, vous devrez peut-être utiliser memcached ou vernis. Cela permet au développeur de dicter combien de temps les données mises en cache resteront dans la RAM du serveur. Naturellement, cela nécessitera des améliorations de développement pour rendre votre application compatible avec memcached / varnish.

Verrouillage de table

• InnoDB effectue le verrouillage au niveau de la ligne, ce qui permet les transactions et les lectures non bloquantes .
• MyISAM ne verrouille que les tables complètes pour chaque INSERT, UPDATE et DELETE .

Épilogue

Vous ne pouvez pas éviter un délai initial après un redémarrage de MySQL. Cependant, une fois que vous avez amélioré MySQL à l'aide des suggestions / informations susmentionnées, vous ne devriez plus rencontrer de retard supplémentaire.

Je voudrais utiliser des outils tels que YSlow ou Firebug, etc. pour déterminer exactement ce qui se passe lorsque vous chargez ladite page et lorsque vous chargez ladite page immédiatement après. Vérifiez s'il s'agit d'un problème de mise en cache et, en outre, vérifiez son fonctionnement lorsque vous accédez à la page en tant qu'utilisateur anonyme, puis en tant qu'utilisateur authentifié. Comparez cela à vos paramètres de performance dans Drupal.

S'il ne s'agit pas d'un problème de mise en cache, utilisez le journal de requêtes de Devel ainsi que les journaux de MySQL pour voir ce qui se passe dans la base de données. De plus, si vous avez des opcode ou des caches similaires améliorant les performances sur le serveur, essayez d’obtenir certains chiffres, puis de les rallumer.

On dirait que le cron est en cours d'exécution.

Vérifiez vos paramètres ici: admin / config / system / cron

J'ai failli abandonner Drupal pour mon dernier projet à cause de cela.

Cependant, il doit y avoir plus d’une cause. Je n'ai pas encore trouvé de solution miracle qui fonctionne à chaque fois que ce problème surgit.

Syslog et Ubuntu / Debain

La première fois que j’ai rencontré le temps de chargement intermittent de 15 secondes, c’était en exécutant drupal sur des systèmes Debian / Ubuntu (dédiés et non partagés). Désactiver le module Syslog était la solution pour moi.

Comme @BetaRide l'a dit, utiliser xDebug ou un autre profileur PHP est extrêmement éclairant.

Toujours un problème - une solution de contournement

Quant à mes autres installations, je suis toujours perdu.

Ce problème est plus perceptible sur mon serveur de développement et mon installation Drupal à faible trafic s'installe.

En guise de solution de contournement, j'ai configuré un travail cron pour charger la page d'accueil du site toutes les 60 secondes ainsi que le script cron de Drupal toutes les 300 secondes. Ce n’est évidemment pas optimal, mais je préférerais que le temps de chargement soit de 15 secondes plutôt que d’être un visiteur humain.

De nombreuses personnes pensent que ce problème pourrait être lié au blocage des processus en arrière-plan synchrones , en particulier ceux liés aux travaux intensifs .

Si tel est le cas, il existe une excellente paire de modules en cours de développement actif par gielfeldt * qui pourraient résoudre ce problème, ou tout au moins, pourraient offrir des indices et aider les constructeurs de site à diagnostiquer et traiter des auteurs spécifiques dans leurs cas. Les deux remplacent les processus synchrone bloquants par des commandes HTTP ou asynchrones non bloquantes et offrent tous deux des rapports pertinents permettant d'identifier les processus problématiques:

• Le processus en arrière-plan et ses modules fournis permettent à la file d'attente des processus en arrière-plan de Drupal d'être traitée de manière asynchrone, de sorte qu'ils ne se bloquent pas. Cela pourrait arrêter le problème. De plus, avec le module Apache Server intégré de Background Process intégré dans la dernière version, il existe un rapport d'interface utilisateur de base, mais en cours d'amélioration, avec des fonctionnalités permettant de superviser, de déverrouiller et d'inspecter les heures de début et les progrès de ces processus. Cela pourrait identifier le processus du problème.
• Ultimate Cron s'appuie sur le processus en arrière-plan pour permettre aux tâches déclenchées par cron de disposer de leurs propres scehdules asynchrones séparées, chacune pouvant être surveillée et arrêtée dans une interface utilisateur. En plus de permettre de séparer les tâches lourdes qui nuisent aux performances du nettoyage régulier, il vous fournit également un rapport contenant des informations pratiques, telles que la durée d'exécution de chaque tâche déclenchée par cron, la dernière exécution, l'état actuel, etc. Cela pourrait également supprimer le blocage et / ou identifier les processus problématiques.

Les deux sont très utiles quand même; pour ce problème, ils peuvent être utilisés pour tester la théorie (sondage très plausible) selon laquelle les blocages sont causés par des processus de blocage synchrones ou des exécutions cron. Potentiellement, ils pourraient résoudre le problème en les exécutant de manière asynchrone au lieu de manière synchrone, et ils pourraient aussi potentiellement offrir des indices sur les processus spécifiques à l'origine du blocage. (soyez averti que leur documentation est vraiment un travail en cours ...

Si, toutefois, ils ne peuvent pas être configurés pour aider du tout, cela suggère que le problème ne se limite pas aux processus d'arrière-plan synchrones. FWIW, je n’ai jamais eu ce problème particulier sur un site depuis que ces modules fonctionnent correctement (pourtant, toucher du bois) - mais je l’ai déjà vu sur mes sites auparavant, ainsi que sur des sites Drupal en direct.

Sachez également que d'autres modules de plug-ins apparentés sont en cours de développement. Par exemple, dans les cas complexes à haute intensité, Ultimate Cron Queue Scaler , qui permet une limitation basée sur des seuils, peut aider à réduire les problèmes de performances liés à cron.

* aucune affiliation, je suis juste un utilisateur très impressionné de leur travail

Comme cela me frappe une fois de plus, je commence à étudier le problème. Je peux certainement confirmer que

1. un appel à drupal_cron_run()déclenché par le noyau de Poorman ajoute ~ 5s au temps de requête sur ma machine de développement. Cela peut être testé par décommentant les essais autour de l'appel à drupal_cron_run()en modules/system/system.moduleensystem_run_automated_cron()
2. effacer tous les caches ajoute ~ 2s au temps de requête sur ma machine dev. Cela peut être testé en faisant un drush cc allet en rechargeant à nouveau la page.

Cela signifie que régler cron sur jamais et ajouter un appel à cron via crontab améliore la situation. Frapper quelques pages souvent utilisées juste après pour recharger le cache améliorerait encore l'expérience de l'utilisateur.

Je ne suis pas sûr cependant de la mise en cache. Je n'ai pas touché les paramètres de cache par défaut pour ce site. Je pense que Drupal est en train de reconstruire toutes les caches de temps en temps peut-être déclenchées par cron, mais je ne suis pas sûr de savoir comment cela est fait. Mais un délai de 7 secondes est à peu près ce que je vois quand je frappe la page après quelques heures.

Des problèmes comme celui-ci peuvent vous rendre fou et lorsque je me trouvais dans des situations similaires, cela aide à comprendre ce qui cause le problème, étape par étape, puis à le tester en tant qu'utilisateur anonyme et connecté. (méthode de la couche d'oignon)

Vous dites que vous commencez à remarquer le problème après avoir joué avec votre propre thème et votre propre code. Je ne sais pas à quel point votre site est complexe ni la logique qui le sous-tend, mais les étapes suivantes vous aideront à trouver la cause:

1. Sur votre serveur, créez un dossier ou un autre compte (cela pourrait être mieux) où vous allez faire une nouvelle installation de Drupal avec la même version que celle que vous utilisez sur votre site. Ensuite, sans ajouter de module ou de thème, testez le temps nécessaire au site pour répondre à la première demande et à la demande suivante. Si tout fonctionne bien, vous pouvez ignorer les problèmes de configuration du serveur. Si votre comportement est le même que celui que vous avez actuellement, vous avez une erreur de configuration avec votre serveur Web ou votre base de données.

2. Si les résultats de l'étape 1 sont corrects et que le serveur répond rapidement et que les requêtes suivantes le sont aussi, installez uniquement le thème de votre site actuel sur le site d'installation propre et testez-le à nouveau. Si tout réagit encore rapidement, votre thème n'est pas le problème et vous devez continuer à l'étape 3, sinon vous devez commencer à déboguer votre thème * 1.

3. Si, après les tests de l’étape 2, le site continue à démarrer rapidement en intégrant les modules de votre site actuel et assurez-vous de tester le temps de réponse après avoir ajouté et activé chaque module * 2.

4. Si, après avoir ajouté le thème et les modules, le site répond toujours rapidement, commencez à ajouter la configuration, créez des types de contenu, importez des vues, des menus de configuration, etc. N'oubliez pas de tester la réponse du site après chaque ajout.

5. L'installation et la configuration sont prêtes et le site toujours rapide, nous allons maintenant transférer les données. Importer des nœuds, des termes de taxonomie, des commentaires, etc. Je sais que je dois ressembler à un enregistrement brisé, mais je le teste toujours à la fin de chaque étape.

* 1 Thèmes de test: ce processus peut être délicat dans un thème super élaboré, voici quelques conseils:

1. Si vous créez un lien vers une bibliothèque externe js ou css, essayez d’en utiliser une copie locale.

2. Dans votre fichier template.php, recherchez les fonctions pouvant comporter des boucles plus longues ou infinies, ainsi que des fonctions de prétraitement et / ou des fonctions de thème de hook.

3. Vérifiez un autre fichier de modèle (page.tpl.php, etc.) et recherchez le traitement brut de tableaux et d'objets par PHP.

4. Si vous utilisez "Vues" et les fichiers de modèles de vues, cochez cette case également.

5. Vérifiez toujours les chemins, optimisez les images, les fichiers js et css. Parfois, les fichiers js peuvent avoir une hauteur importante lorsque vous utilisez plusieurs extraits de code dans un seul fichier.

* 2 Modules de test : les modules de test sont un peu différents car l'utilisation de manipulations intensives avec PHP est autorisée. Voici quelques indications:

1. Les modules supportés par la communauté (CCK, Views, etc.) ont une liste de problèmes sur drupal.org et vérifiez-les pour voir s’il existe un problème concernant votre problème et s’il est probable qu’il existe un correctif pour le résoudre.

2. Propre module personnalisé, bien si vous avez codé, vous devez le réparer, non? Vérifiez votre codage et vérifiez l’utilisation des fonctions par rapport à api.drupal.org. Vous pourriez utiliser une fonction de dépassement au lieu d’un hook.

3. Module de code personnalisé partagé Internet, procédez comme à l'étape 2, mais cette fois-ci, vous pouvez également contacter l'auteur du module d'origine et l'informer du problème.

4. Si votre site est une mise à niveau (D5 -> D6 -> D7), vérifiez les scripts de migration ou de mise à niveau (généralement dans le fichier module.install). Vous aurez peut-être besoin d'un "index" supplémentaire sur la nouvelle configuration de la table pour accélérer la requête SQL lente X .

5. Si vous sentez que vous avez une vision en tunnel du problème, prenez le temps de faire quelque chose et faites une autre activité complètement non liée, puis revenez plus tard pour revenir sur le problème.

6. Si vous pointez le problème sur une section de code, mais que vous ne savez pas comment résoudre le problème, essayez d'expliquer ce que cette section est censée faire à une personne qui n'a aucune idée de la programmation ou du fonctionnement de Drupal. prêt à être surpris.

Remarque: ne vous inquiétez pas si, après avoir reconstruit votre site, tout commence à fonctionner comme un charme qui compte parmi les meilleures fonctionnalités des ordinateurs.

Vérifiez que vous n'avez supprimé aucun module sans les désinstaller. Cela provoque un délai car Drupal essaie de trouver les fichiers mais ils ne sont plus là.

Supprimez les références dans la table des variables si les modules n'existent plus.

Un APM Web tel que newrelic est le meilleur outil pour repérer les problèmes de performances. J'ai eu des sites appelant une ou deux lignes de code qui faisaient des bêtises, chargeaient des tableaux inutiles à des époques étranges, et faisaient d'autres choses qui étaient plutôt invisibles jusqu'à ce que nous les traquions avec un APM.

Quelqu'un a mentionné que GoDaddy serait lent. De nombreuses sociétés d'hébergement basées sur le cloud auront également ce délai initial, car des services tels qu'AWS le possèdent. Il est moins coûteux de déprioriser automatiquement les serveurs, et il faudra attendre une seconde ou deux pour qu'ils se «réveillent».

Par exemple, Pagodabox a 3-4 secondes pour le premier octet, jusqu'à ce que le serveur soit joyeusement réveillé. En fait, Pagodabox a monétisé pour garder le serveur éveillé, vous permettant ainsi de payer un supplément pour «caffiéniser» votre site.

En outre, un CDN peut vous aider. Votre serveur web / db ne sera pas chargé de servir des pages ou des images en cache. Un bon tutoriel ici: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

Et ... WebPageTest me rend heureux. http://www.webpagetest.org/ Comparez les temps de chargement de la planète et avec différents navigateurs Web gratuitement. Utilisez-le pour obtenir des résultats concrets, quels que soient les changements que vous apportez.

le problème pourrait être n'importe où.

1. Assurez-vous que vous n'avez pas activé le mode débogage sur un thème ou un module. Par exemple, dans de nombreux thèmes, il existe une option pour régénérer le registre de thèmes.
2. Si vous utilisez un hébergement partagé comme Godaddy, une demande de 15 secondes est normale.
3. Convertissez votre site ou votre page de couverture en base de code à l’aide du module d’exportation Drush CTools . Cela éliminera tout appel de base de données et votre site sera entièrement exécuté à partir de php.
4. Si vous avez encore des problèmes, utilisez les paramètres Devel en activant query loget les page timeroptions à admin/config/development/devel. Voir lequel des deux prend plus de temps pour générer une page entière.
5. Redémarrez votre serveur si rien ne fonctionne.
6. Dans le pire des cas, installez XHProf pour voir où tout va mal.

Voici comment j'ai résolu le problème pour mon installation. Ce n’est pas une vraie solution car je ne saurais vous indiquer la source exacte du problème (s’il en existe un), mais c’est une bonne solution

1) Agréger CSS (paramètres de cache). Cela a réduit la latence de moitié

2) Définissez cron sur jamais (et exécutez-le en externe) - Remarque: j'ai eu des erreurs "essayant de démarrer cron alors qu'il est déjà en cours d'exécution". Je pense qu’il essayait de démarrer cron à chaque lancement, mais comme il échouait, la page cron ne mentionnait pas la dernière tentative, mais plutôt le dernier succès.

3) Configurez un travail cron qui appelle la page d'accueil avec Lynx toutes les 30 minutes.

Tout cela sur un serveur d'hébergement partagé. Ce n'est pas optimal mais ça marche

Je suggérerais d'utiliser un cache frontal du module Boost (en supposant que vous soyez sur un hébergement partagé) ou de Varnish. Cela fonctionnera mieux si les accès à votre site sont principalement anonymes et si le contenu de la page est, pour la plupart, non dynamique (les pages ne changent pas beaucoup).

Ces solutions enregistrent les pages rendues lors du premier accès, puis servent le code HTML pré-rendu au lieu de parcourir l'intégralité des processus d'amorçage, de création de page et de thématisation Drupal. décris lequel "va dormir" et prend trop de temps à te réveiller.

Le seul inconvénient est que (du moins pour Boost), vous devrez effacer le cache lorsque le contenu du site change. Si vous voulez vous assurer que le site est entièrement mis en cache avec le contenu actuel, vous pouvez exécuter drush cc all, puis curl ou wget contre le site complet périodiquement via cron.