Accueil > Blog-notes > Drupal et mySQL sont sur un serveur...

Drupal et mySQL sont sur un serveur...

jeudi 11 juin 2009

Voir l'article original

Je suis tombé un peu par hasard sur un article du blog de la société Adyax, où un des développeurs explique comment il a résolu ses problèmes de charge SQL sur un site Drupal qui venait d’être mis en ligne.

Curieux par nature, et toujours à la recherche de bons conseils, je lis alors l’article en détail, espérant trouver l’une ou l’autre astuce transposable à mon travail.

Je vous donne le lien vers l’article qui n’est plus disponible à l’heure où j’écris ce billet [1], et donc le lien vers le cache de votre moteur de recherche préféré vous permettra de le lire.

J’ai tiqué d’abord sur la difficulté qu’a eu le développeur à trouver la requête fautive, un peu étonné que Drupal n’offre pas un outil comparable à ?var_profile=1&var_mode=calcul qui permet d’un coup d’oeil d’avoir l’ensemble des requêtes SQL lancées au calcul d’une page :

  • classées par temps total d’execution (soit la somme des temps de chaque execution si la requête est appelée plusieurs fois)
  • avec la requête exacte, ce qui permet de la rejouer à la main
  • avec la référence à la boucle qui produit cette requête, ce qui permet de la retrouver dans le code

Puis j’ai vu la requête fautive, que je vous remets ici juste pour le plaisir :

Pourquoi tant de haine ?

Ce que je crois avoir compris de l’article (si un expert Drupal est dans la salle, qu’il n’hésite pas à me corriger sévèrement :p si j’ai tout faux) est que ce genre de requête est générée par le célèbre et très usité module views de Drupal qui sert à construire des listes. Et que cette requête est le résultat d’une concaténation de plusieurs conditions et jointures chacune ajoutée par le(s) dévelopeur(s) à travers le système de hook de Drupal.

De toute évidence ce système conduit à la génération d’une requête qui n’est pas optimisée.

Avec un peu de réflexion, cela se comprend : si la requête est construite à chaque service de la page, il n’est pas raisonnable d’ajouter à ce coût de construction de la requête un coût d’optimisation (qui par nature est toujours important) qui ne sera rentable que sur des grosses requêtes.

D’où le résultat.

Et SPIP alors ?

vous demandez-vous, fort interloqué que le nom de votre outil préféré n’ait pas encore été cité sur ce blog pourtant franchement partial, d’habitude.

La différence fondamentale de SPIP par rapport à autres outils est son système de boucle. J’ai déjà eu l’occasion de vous vanter l’avantage de cette sur-couche que certains développeurs PHP exècrent pourtant méthodiquement.

Profitons de l’occasion pour voir une nouvelle fois d’autres avantages de cette sur-couche.

Des requêtes « préparées »

Un des premiers avantages est que les squelettes de SPIP sont « compilés » à l’avance (le terme de compilation est ici inexact mais a l’avantage de bien faire passer l’idée) : l’ensemble des squelettes est converti en code PHP et en requête SQL une fois pour toute.

Du coup, il est acceptable de payer le coût d’un certain nombre d’optimisations : lorsqu’un champ demandé nécessite une jointure, il est par exemple possible d’analyser la requête déjà construite pour vérifier que la jointure nécessaire n’est pas déjà là. Et de ne l’ajouter que lorsque c’est nécessaire.

Des critères optimisés

Un grand nombre de critères existent nativement dans SPIP qui permettent la sélection des données dans les boucles. Ces critères ont pu être optimisés pour que la requête produite soit optimale en général.

Une optimisation systématique

À un développeur qui me disait dernièrement : je préfère faire mes requêtes à la main car je peux et je sais les optimiser, j’ai fait remarquer que oui, sûrement : un bon développeur peut optimiser une requête mieux que n’importe quel outil.

Mais un site est le produit de centaines, voire des milliers de requêtes générées.
 combien le bon développeur en optimisera-t-il vraiment ?
 combien de requêtes avez-vous pris le temps d’optimiser sur votre dernier projet web ?
 comment savez-vous que ce sont les requêtes qu’il était le plus intéressant d’optimiser ?

À votre avis, sur un site qui compte un millier de requêtes différentes, qu’est-ce qui est plus intéressant :
 avoir un outil qui gagne gratuitement, et sans effort, 1 % de charge sur chaque requête SQL ?
 avoir un bon développeur qui est capable de gagner 50 % de charge sur 1 % des requêtes après 2 jours de travail ?

Le grand intérêt d’un outil qui optimise les requêtes est qu’il le fait systématiquement.

Des outils d’analyse

Avoir une optimisation de base systématique des requêtes SQL n’empêche pas d’utiliser intelligemment votre développeur. Et pour ça l’outil d’analyse des requêtes d’une page ?var_profile=1 est redoutable [2].

En effet, en listant toutes les requêtes lancées pour le calcul d’une page classées par temps d’execution, il mets en avant les 2 ou 3 requêtes qui vous génèrent 50 % du temps de calcul. Et il devient très confortable de faire travailler vos neurones (ou ceux de votre développeur expert) sur ces quelques requêtes, en mesurant tout de suite les gains obtenus.

Des possibilités d’optimisation

En effet, les requêtes ne sont pas écrites directement, mais sous forme de boucles. Lorsqu’une requête peu performante est trouvée, il est alors possible de modifier l’implémentation de la boucle et/ou du critère qui provoque cette requête.

La surcouche n’exclut donc pas du tout les optimisations manuelles, mais vous permet en plus d’optimiser d’un seul coup toutes les boucles semblables, sans avoir à repasser dans tout le code de votre projet pour appliquer la même optimisation partout.

La cerise sur le gâteau

Last but not least, comme disent nos amis américains. Le système de cache de SPIP.

Une autre grande différence de SPIP avec d’autres CMS, comme l’excellent Drupal, est son système natif de cache. Il s’agit, au demeurant, d’un avantage direct de son système de squelettes. Lorsque le résultat d’une page a été calculé (les requêtes SQL évaluées, le php executé...) pourquoi recommencer la seconde d’après si les données en base n’ont pas changées ?

Avec SPIP 2.0, le système de caché a été simplifié pour plus d’efficacité. Exit toute l’artillerie complexe, et décriée à raison par certains hébergeurs, qui visait à deviner si les données d’une page avaient changées ou non. La règle est simple :
 les données éditoriales n’ont pas changées depuis le dernier calcul de la page ? Hop SPIP la ressert sans plus de formalité, à la vitesse de l’éclair.
 les données ont changées : pas de problème, SPIP évalue le PHP préparé, avec ses requêtes déjà construites. Vous n’avez rien perdu par rapport à d’autres CMS.

Du coup, SPIP est capable de tenir le choc face à un buzz qui voit plein de monde arriver sur une page tout d’un coup. Là où d’autres CMS souffrent. Souffrent. Et tombent.

SPIP, pour un site qui fonctionne à moindre coût

Je crois que vous avez un peu compris où je voulais en venir.

Sérieusement, au delà de l’effet de mode dont certains CMS comme Drupal bénéficient, il ne faut pas perdre de vue les fondamentaux techniques lorsqu’on choisit un outil.

L’utilisation de Drupal comme plateforme est souvent justifiée par les prestataires professionnels par son efficacité supposée en terme de développement et de coûts associés.

Si tant est que cela serait vrai, j’ai quand même envie de rappeler que le coût de fonctionnement d’un site peut très vite devenir beaucoup plus important que le coût initial de développement.

Et de finir en boutade, avec un fond de vérité :
Pour construire un site qui fonctionne à moindre coût, choisissez SPIP.
Pour vendre des jour.homme, choisissez Drupal.

Documents joints

Notes

[1j’ai twitté, ça a retwitté, le site serait-il tombé ?

[2Les curieux se reporteront au PDF joint qui montre le résultat sur la home de http://www.spip-contrib.net.

Commenter l'article original