MySQL 5.6 rock suite

avril 5, 2012

Voici la suite du post MySQL 5.6 rock, dans lequel je test MySQL 5.5 & 5.6, MariaDB 5.3 & 5.5 et Percona server 5.5.

Pour cet article, toujours un bench. Le contexte est assez proche, à la différence près que cette fois les serveurs sont testés en lecture (65%) et écriture (35%).

 
 
Les règles du bench

sysbench, options read/write complex, 128 connexions concurrentes

Moteur InnoDB, 30 millions de lignes, 6.7 Go de données

Pas de warmup, le disque doit être sollicité au maximum.

Les tests ont été lancé 4 fois sur chaque version, avec restart du serveur entre chaque run.

Les confs sont proche cad les paramètres communs à toutes les versions ont les mêmes valeurs, les autres, leur valeur par défaut

La moyenne donne les résultats suivants:

95 centile (en ms)

    • Percona 5.5.12: 182.135
    • MariaDB 5.3.5 *: 132.3025
    • MariaDB 5.5.20: 183.1275
    • MySQL 5.5.22: 160.8525
    • MySQL 5.6.4: 153.6175

 

dasini.net - 95 centile for R/W i/o bounds

 
 
 

Nombre de transactions par seconde

  • Percona 5.5.12: 2170.5
  • MariaDB 5.3.5 *: 2016.505
  • MariaDB 5.5.20: 2134.9125
  • MySQL 5.5.22: 1680.7525
  • MySQL 5.6.4: 1738.4775

 

dasini.net - TPS for R/W i/o bounds

 
 
 

Mes commentaires

En matière de temps de réponse, MariaDB 5.3 (branche MySQL 5.1 + nombreuses améliorations apportées par Monty Program AB) est sans (trop de) surprises, celui qui donne les meilleurs temps de réponse sur 95 % des meilleurs requêtes (95 centile). Mais il sera moins scalable du fait de son unique Buffer pool.

La bonne surprise vient de MySQL 5.6 où le temps de réponse est significativement meilleur qu’avec la branche 5.5 (de 5 à 15%).

En ce qui concerne débit maximum, les TPS, MySQL est en retrait. Il plafonne aux environs des 1700 TPS alors que MariaDB & Percona dépassent sans souci les 2000 !

Cet écart (20% tout de même !!!) s’explique sans doute par de meilleurs performances d’XtraDB (qui équipe MariaDB & Percona) en matière de débit, par rapport à son cousin InnoDB (XtraDB étant un fork d’innoDB, développé par Percona).

Le produit s’améliore donc, et ce même sans tuning particulier, c’est une très bonne chose !

Ceci dit, l’optimisation du serveur MySQL risque de commencer dès le choix de la distrib, en prenant en compte le workload (lecture seule, écriture seule, lecture+écriture), le besoin (temps de réponse, débit maximal), …

Avoir dans son équipe un profile MySQL expérimenté devient de plus en plus nécessaire. Et ça je trouve que c’est plutôt une bonne chose 😉

 
 
 

Divers

 

3 Responses to “MySQL 5.6 rock suite”

  1. […] 2ème partie de l’article … […]

  2. Hello,

    As-tu pu tester l’influence du MRR (Multi Range Read) ?

    http://www.mysqlperformanceblog.com/2012/03/21/multi-range-read-mrr-in-mysql-5-6-and-mariadb-5-5/

    En IO bound, MySQL 5 est censé s’effondrer par rapport à MySQL 6.

  3. Salut Denis,
    sysbench en mode OLTP génère des requêtes « orientée web » ie assez simple (même avec le mode complex).
    Les améliorations apportée à l’optimiseur (BKA, MRR, ICP…) ne sont pas vraiment utiles dans ce cadre.
    Ovais lui utilise TPC-H avec la requête 10, plus orientée décisionnel/OLAP. En d’autres termes, on ne teste pas la même chose.
    Lui montre que MySQL 5.6 & MariaDB 5.5 est maintenant une alternative (plus) sérieuse dans un mode non web (pour simplifier)
    Moi, je montre que dans un contexte web, le produit s’améliore encore.
    Bref, que du bon 🙂

Leave a Reply