Améliorer les performances de Drupal de 80%
Drupal est un peu connu pour le nombre de requêtes de base de données effectuées contre une base de données. Lorsqu'il y a des milliers d'utilisateurs simultanés à servir, la base de données peut rapidement devenir un goulot d'étranglement majeur. C'était le cas avec http://kwestiasmaku.com - un site web très populaire avec des recettes. Le site est visité par des millions de passionnés de cuisine.
Lorsque nous avons commencé notre collaboration avec KwestiaSmaku, nous nous sommes initialement concentrés sur l'ajout de nouvelles fonctionnalités au site. Finalement, cependant, la popularité croissante nous a forcés à examiner l'application du point de vue des performances.
Nos développeurs Drupal ont effectué de nombreuses optimisations de performance de divers types et ci-dessous n'est qu'un exemple de ce que nous réalisons souvent.
Analyse
Pour résoudre les goulots d'étranglement en matière de performances, nous avons d'abord voulu comprendre ce qui cause la plus grande charge. Généralement, il y a deux possibilités :
- Le code du site web est inefficace (il peut contenir des erreurs évidentes qui causent des requêtes de base de données supplémentaires et inutiles, parfois répétées dans des boucles et des itérations).
- Il n'y a peut-être pas d'erreurs directes. Vous pouvez cocher toutes les cases pour construire le site à la manière de Drupal en suivant toutes les meilleures pratiques, mais avec un certain volume d'utilisateurs, rencontrer un goulot d'étranglement (généralement lié à la base de données).
Nous n'avons pas construit KwestiaSmaku mais avons pris en charge sa maintenance, nous avons donc d'abord voulu nous assurer que les modules personnalisés ne contenaient pas de surprises qui correspondraient à l'option numéro un ci-dessus. Nous avons utilisé x-debug profiler et blackfire pour cela. Ces outils sont très similaires à bien des égards, mais chacun offre aussi des options uniques. Les deux vous permettent d'observer comment la page est générée et combien de temps est passé à chaque fonction dans la pile d'appels.
Une chose que nous avons trouvée avec ces outils était le module browsercap, qui était installé mais non utilisé à des fins quelconques. Cependant, il interrogeait la base de données de manière substantielle pour chaque requête de page. En dehors de cela, nous avons trouvé quelques éléments sous-optimaux que nous pouvions corriger, mais rien d'assez conséquent pour nous sortir du goulot d'étranglement de la base de données. Nous devions passer à la phase 2 - optimisation des performances.
L'un des meilleurs outils pour comprendre ce qui se passe avec votre serveur est New Relic. Les données recueillies par cet outil ont confirmé ce que nous soupçonnions dès le début : les requêtes les plus lourdes et les plus chronophages étaient celles générées par le module de vues. KwestiaSmaku utilisait des vues assez complexes pour afficher des listes de recettes sur la page d'accueil et dans les catégories. Le module de vues est excellent mais c'est une arme à double tranchant - vous pouvez rapidement créer des listes complexes d'entrées mais cela génère de grosses requêtes de base de données lourdes avec de multiples JOINS et sous-requêtes imbriquées.
API de recherche Solr
Outre la mise en place d'un cache basé sur le temps ou la création d'une base de données esclave et son utilisation pour alimenter la vue, il n'y avait pas grand-chose que nous pouvions faire pour optimiser les requêtes de base de données générées par les vues. Pour contourner ce problème, nous avons proposé de déplacer l'ensemble de la vue d'une requête de base de données vers un index basé sur Apache Solr. Nous utilisions déjà Solr pour alimenter la fenêtre de recherche du site, donc la seule chose que nous devions faire était de créer un autre index qui contiendrait les données nécessaires pour afficher sur les listes de recettes.
Avec Solr, nous avons supprimé les requêtes de base de données lourdes, diminuant substantiellement la charge sur la base de données. Ceci est clairement visible sur les graphiques de New Relic de cette période. Nous avons publié le changement dans la nuit du 7 au 8 novembre et le jour suivant, la base de données était déjà sous beaucoup moins de stress.
Ensuite, le 8 novembre, nous avons désactivé le module browsercap qui exécutait encore une requête inefficace (la couleur bleue sur le graphique)
Grâce au passage de la base de données à l'index Apache Solr, nous avons complètement éliminé les requêtes de base de données les plus inefficaces et chronophages. Les requêtes les plus longues sont désormais 5 fois plus courtes qu'avant le changement (les pics nets sur les graphiques sont les sauvegardes nocturnes)
Grâce à nos optimisations, kwestiasmaku.com peut croître davantage sans avoir besoin de changer de serveur ou de mettre en œuvre une infrastructure de serveur complexe.
Si vous avez un site web qui présente des problèmes de performances, faites-nous signe. Dans le cadre de la fourniture de services de développement Drupal, nous améliorons souvent les performances des sites web.
