High Performance MySQL [Ch. 2 : Benchmarker MySQL]

Pourquoi benchmarker

Une base de développement de quelques centaines de lignes ne vous apprend presque rien sur la production. Les benchmarks permettent de soumettre le système à une charge choisie et de l'observer : ce qu'il peut encaisser, où il plie, si une hypothèse sur le matériel ou le schéma tient, et comment il se comporte dans les cas limites que vous préféreriez ne pas rencontrer en production. C'est aussi la façon honnête de comparer deux conceptions avant de s'engager sur l'une d'elles.

Leur faiblesse, c'est que la charge est inventée. Le trafic réel est désordonné, irrégulier et inégalement réparti sur les données. Un benchmark qui l'ignore produit des chiffres précis et faux.

Où les benchmarks mentent

• Volume de données. Un test de 1 Go pour une table de 100 Go tient entièrement dans le buffer pool et mesure la mémoire, pas le stockage.
• Distribution. Des clés uniformément aléatoires répartissent la charge de façon égale ; les vrais utilisateurs martèlent quelques lignes chaudes et laissent le reste froid.
• Rythme d'arrivée. Enchaîner les requêtes aussi vite que possible ne modélise aucun client réel et crée une contention qui n'existe jamais en production.
• Extrapolation. Un serveur qui supporte 10× plus de transactions par seconde ne signifie pas que l'activité peut croître de 10×. La croissance apporte de nouvelles fonctionnalités et des requêtes plus lourdes, pas seulement davantage de celles d'aujourd'hui.

Pile complète ou composant isolé

Benchmarker l'application entière, du HTTP jusqu'à la base, répond à la question qui intéresse les utilisateurs : à quelle vitesse va le produit ? Cela capture les sauts réseau, les caches applicatifs et la sérialisation, mais c'est coûteux à mettre en place et bruité à interpréter.

Benchmarker MySQL seul est le bon outil pour des questions plus ciblées : laquelle de deux requêtes coûte le moins, si un changement de schéma aide, ce que fait une variable de configuration. Moins de pièces mobiles, c'est des résultats que l'on peut attribuer.

Quoi mesurer

Ces métriques se complètent. Une excellente latence mono-thread ne dit rien de ce qui se passe avec 64 clients simultanés.

Mener un benchmark fiable

• Choisissez délibérément entre standard et sur mesure. Une suite standard doit correspondre à votre charge : un benchmark analytique comme TPC-H vous apprend peu de chose sur un service OLTP.
• Partez de données réelles. Prenez un instantané de la production (anonymisé si nécessaire) et conservez-le pour que chaque exécution parte du même état.
• Rejouez de vraies requêtes. Capturez les logs de requêtes de production sur des périodes représentatives au lieu d'inventer un mélange de requêtes.
• Faites un échauffement, puis mesurez assez longtemps. Les caches se remplissent et le débit oscille avant de se stabiliser. En règle générale, continuez à mesurer au moins aussi longtemps qu'a duré l'échauffement.
• Enregistrez tout, à l'état brut. Des données en trop coûtent du disque ; des données manquantes coûtent une nouvelle exécution. Gardez les échantillons bruts pour pouvoir les agréger autrement plus tard.
• Automatisez. Une exécution scriptée est reproductible, et c'est la reproductibilité qui rend deux configurations comparables.

Outils

Pour MySQL seul, mysqlslap est livré avec le serveur : il peut créer un schéma de test, exécuter un fichier de requêtes ou des requêtes générées sur de nombreuses connexions, et rapporter les temps. sysbench est le choix courant pour les benchmarks de type OLTP et matériels. Pour les tests de pile complète, des générateurs de charge HTTP pilotent l'application de l'extérieur. Quel que soit votre choix, maîtrisez bien un petit ensemble d'outils et scriptez autour.

Comment cela apparaît dans QueryCrack

QueryCrack ne note délibérément pas le temps réel d'exécution. Le temps dépend de l'état du cache, des voisins et de la chance, exactement le bruit contre lequel ce chapitre met en garde. Le nombre de lignes examinées est déterministe pour un plan et un jeu de données donnés : c'est donc une métrique de benchmark sans variance, et la même requête obtient toujours le même score.

Questions fréquentes