Teorem's

La conférence MySQL’2010 s’est finie hier, mais je pense que je vais avoir de quoi blogger pour plusieurs semaines.

Deux des sessions (voir ici et ici) auxquelles j’ai assisté m’ont donné quelques bonnes pistes pour avancer beaucoup plus rapidement sur les problèmes de performance d’applications PHP tournant avec un backend MySQL.

L’instrumentation va s’appuyer sur :

• la possibilité d’utiliser des variables (mise à jour par des scripts PHP) dans les logs apaches avec MOD_LOG_CONFIG
• la possibilité de commenter les requêtes SQL envoyé à MySQL et de retrouver les informations en question dans les logs
• les impressionnantes capacités des outils trouvés dans le kit MaatKit (www.maatkit.org).

Tout cela va permettre de retrouver facilement les éléments d’une application qui ont besoin d’être optimisés, et de vérifier par la suite que les travaux d’optimisation ont effectivement portés leurs fruits.

Les outils MaatKit permettront aussi de gérer la mise en place de « query reviews », gestion qui pourra se faire en même temps que le traitement des logs d’instrumentation. Le principe est simple : on traite régulièrement les logs de production pour en extraire des informations sur les classes de requêtes exécutées sur son serveur MySQL. On peut ensuite choisir les requêtes qui posent des problèmes de performance et indiquer qu’elles ont été revues, corrigées ou que tout allait bien. Et si des modifications de configuration ou de taille de données ont un impact sur ces requêtes, on saura détecter la modification de performances et agir pour rétablir la situation.

Je vois déjà chez qui je pourrais mettre cela en place pour faciliter l’amélioration des performances de leurs serveurs.

Les deux premiers keynotes d’hier ont présenté des alternatives à MySQL et surtout un esprit open-source que certains voient comme ayant déserté le management de MySQL AB depuis quelques années.

D’un côté, nous avions Brian Aker qui nous présentait Drizzle, et de l’autre nous avions Michael Widenius (le fondateur et grand architecte de MySQL) qui nous présentait MariaDB.

Ce sont deux projets qui ont l’ambition de faire les choses correctement d’un point de vue du process de développement open-source :

• faire des releases le plus rapidement possible et le plus souvent possible
• intégrer les feedbacks mais aussi les patchs de code fournis par la communauté
• fournir un produit de grande qualité qui répond rapidement aux besoins de ses utilisateurs

Je dois avouer que les deux projets m’ont enthousiasmé au même niveau que la qualité des présentations. Brian Aker était enthousiaste et convaincant, avec un projet qui (de mon point de vue) est intéressant techniquement et va sûrement faire avancer les choses dans le monde du traitement scalable des données, tout en étant en phase avec son temps et avec déjà de vrais utilisateurs. Michael Widenius était dur à suivre et donnait l’impression de vouloir revivre le début de MySQL AB avec une offre (oui, je ne parle même pas de projet !) d’une alternative à MySQL qui ne propose que de gérer l’évolution du soft  mais sans réelle innovation pour s’en différencier réellement. La description de l’offre de services de sa boîte m’a quand même permis de découvrir un outil de getsion et de monitoring de MySQL qu’il me faudra regarder de plus près : WebYog.

Le dernier keynote portait sur les possibilités d’amélioration du support de la communauté (user et devs) grâce à Oracle et il pourrait effectivement se passer des choses intéressantes pour rendre la communauté des utilisateurs et développeurs (third party, pas les dévs du coeur de MySQL) plus vivante.

La journée a été très bien remplie et les sessions ont confirmé ce que le premier keynote nous annonçait ce matin : MySQL 5.5 s’annonce très intéressante du point de vue des performances et de la scalability.

Performances de MySQL 5.* en fonction du nombre de CPUs

StressTest de MySQL 5.5

Les deux graphes que j’ai récupéré dans une présentation montrent que la version 5.5.3 de MySQL scale de manière linéaire avec le nombre de CPUs sur la machine sur laquelle elle tourne. De plus, on peut voir sur le graphe de gauche qu’il y a une amélioration manifeste par rapport à la 5.1. Avec des annonces récentes des fondeurs sur des puces à plus de 8 coeurs, ces perfs prennent tout leur sens.

Ces performances sont possibles car les devs ont fait un boulot monstrueux sur les goulots d’étranglement liés à des mutexs utilisés à différents moments du traitement des requêtes. En bref, ils ont éliminés les endroits où des processus s’attendaient pour libérer l’accès à une ressource partagée.

Ce travail sur les mutex a amené par exemple à l’intérieur d’InnoDB des perfs bien meilleure en situation de recovery : un bench qui prenait 7 heures auparavant, ne prend que 14 minutes maintenant.

De manière générale, l’annonce choc était que le 5.5 était 3 fois plus rapide en read et 5 fois plus rapides en write que la version précédente.

Les deux autres point intéressants sont des nouvelles features : la réplication semi-synchrone qui améliore sensiblement la robustesse des slaves et l’instrumentation du code permettant d’avoir plein d’informations qui faciliteront les investigations sur les performances.

En dehors des aspects techniques, le keynote de ce matin a confirmé qu’Oracle continuera à supporter le modèle « open-source » de MySQL. On verra l’année prochaine ce que cela donne sur le long-terme.

Mise à jour : plus d’informations détaillées sur les modifications, jetez un oeil sur l’article de Jeremy Zawodny

Je n’ai malheureusement pas fait de grandes découvertes dans la journée d’hier.

Je ne regrette pas (trop) les sessions choisies, bien que je sois un peu frustré de ne pas avoir pu aussi assister aux explications de l’équipe MySQL Cluster. J’ai eu droit à un bon rappel de ce qu’il faut savoir pour faire du troubleshooting de performances MySQL et cela m’a permis de découvrir deux ou trois nouveaux outils qui seront bien utiles.

Je ne ferai pas un résumé de ce que j’ai glané (vous n’aviez qu’à venir vous-même, héhé !) mais je tiens à partager quelques petites choses.

La session sur les performances a été illustrée par des « case studies » (plutôt des « horror stories » selon moi), ce qui était une très bonne chose pour décrire l’application de la méthode d’investigation du présentateur. Et celui-ci a insisté que tout ce que disait le client devait être considéré comme des informations et pas forcément comme des faits. Il a illustré cette maxime avec ce client (qu’il n’a pas nommé) qui après plusieurs heures d’investigation s’est rendu compte que la page de status de ses disques Raid était cachée dans son navigateur et qu’il avait en fait un disque HS (ce qui dégrade fortement les perfs même si le système continue à tourner grâce à la redondance des disques). Il ne faudra pas s’étonner si je prends tout ce que l’on me dit avec des pincettes à l’avenir.

La session sur le caching, replication et sharding, bref comment mettre à l’échelle une base de données, était amusante en cela que le présentateur a tout fait pour nous convaincre de ne faire du sharding qu’en dernière extrémité. C’est dommage, j’étais venu justement pour en apprendre plus sur les techniques en question. Je ne suis pas reparti bredouille quand même. Je dois avouer aussi que le jetlag m’a rattrapé dans la première partie de la session. L’année prochaine, il faudra que je trouve un moyen de venir plusieurs jours avant le début de la conf. Le présentateur m’a quand même convaincu d’acheter le livre « High Performance MySQL ». Cela me fera une bonne lecture pour le retour, accompagné du livre des auteurs de dbnewz (dont mon copain Pascal Borghino) : « Audit et Optimisation MySQL 5″.

Les keynotes vont commencé dans une heure et demi. Je ne pense pas qu’il y aura de grande nouvelle à la Steve Jobs, mais ce sera sans doute intéressant à suivre.

Je me relance dans l’écriture d’articles pour le blog de Teorem à l’occasion de la conférence MySQL 2010. Je me suis fixé un programme assez chargé pendant la conférence (vous pouvez jeter un oeil sur ma sélection de sessions).

J’ai choisi cette année de me concentrer à tout ce qui est relatif à mon coeur d’expertise : les performances, la scalabilité en terme de charge, mais aussi en terme de données. Je suis notamment curieux de voir ce que les nouveautés apportent à MySQL en terme de partitionement.

Je vais donc passé quatre jours assez intense en terme de contenu, enfermé dans le Convention Center de Santa Clara. Mais vu ce qu’il tombe comme flotte (et cela ne va pas s’arrêter semble-t-il), ce n’est pas un mal !