Si vous avez déjà eu besoin de mesurer le temps que prend une requête sur un serveur inactif, vous avez sans doute déjà rencontré ce cas de figure :

1ère exécution :

mysql> SELECT COUNT(*) AS total,YEAR(birth_date) AS birth_year
FROM employees INNER JOIN salaries USING(emp_no)
WHERE first_name LIKE '%m%' AND salary > 50000 AND to_date < '2010-12-31'
GROUP BY birth_year;
[...]
14 rows in set (11.70 sec)

Exécutions suivantes :

mysql> SELECT COUNT(*) AS total,YEAR(birth_date) AS birth_year
FROM employees INNER JOIN salaries USING(emp_no)
WHERE first_name LIKE '%m%' AND salary > 50000 AND to_date < '2010-12-31'
GROUP BY birth_year;
[...]
14 rows in set (0.00 sec)


Une telle différence ne peut s’expliquer que par la présence d’un cache : à la première exécution, le cache étant vide, la requête a été exécutée et mise en cache, alors que pour les exécutions suivantes, le cache était rempli et la requête a pu être servie directement. Une question demeure : de quel cache s’agit-il ?

Le 1er cache auquel on peut penser est le cache de requêtes (plus connu sous sa dénomination anglo-saxonne de query_cache). C’est le cache qui est visé par la directive SQL_NO_CACHE :

mysql> SELECT SQL_NO_CACHE COUNT(*) AS total,YEAR(birth_date) AS birth_year
FROM employees INNER JOIN salaries USING(emp_no)
WHERE first_name LIKE '%m%' AND salary > 50000 AND to_date < '2010-12-31'
GROUP BY birth_year;
[...]
14 rows in set (2.95 sec)


mysql> SELECT SQL_NO_CACHE COUNT(*) AS total,YEAR(birth_date) AS birth_year
FROM employees INNER JOIN salaries USING(emp_no)
WHERE first_name LIKE '%m%' AND salary > 50000 AND to_date < '2010-12-31'
GROUP BY birth_year;
[...]
14 rows in set (2.89 sec)


mysql> SELECT SQL_NO_CACHE COUNT(*) AS total,YEAR(birth_date) AS birth_year
FROM employees INNER JOIN salaries USING(emp_no)
WHERE first_name LIKE '%m%' AND salary > 50000 AND to_date < '2010-12-31'
GROUP BY birth_year;
[...]
14 rows in set (2.96 sec)

(Sujet annexe : je ne m’attache pas ici à la configuration du cache de requêtes, voici un excellent tutoriel pour ceux qui se posent la question)

SQL_NO_CACHE désactive-t-elle tous les caches ? Eh bien non, et il est facile de s’en convaincre : la toute 1ère exécution de la requête prenait près de 12s, la 1ère avec le SQL_NO_CACHE moins de 3s. Quels sont donc ces autres caches ?

Le seul cache géré par le serveur MySQL étant le cache de requêtes, il faut descendre au niveau des moteurs de stockage pour mieux comprendre ce qui se passe. Pour MyISAM, il existe un cache pour les index dont la taille est paramétrable via la variable key_buffer_size et un cache pour les données, qui est tout simplement le cache du système de fichiers (donc pour lequel il n’existe aucun moyen d’agir au niveau de MySQL). Pour InnoDB, un seul cache existe pour les données et les index; sa taille est donnée par la variable innodb_buffer_pool_size.

Il est très important de noter que SQL_NO_CACHE n’a aucune influence sur ces 3 caches. C’est pour cette raison qu’il faut faire très attention quand on fait des tests en mesurant des temps d’exécution sous peine d’obtenir des résultats fantaisistes, par exemple quand on cherche à déterminer si le passage en une version supérieure pourrait permettre d’améliorer les performances. Les effets des caches peuvent d’ailleurs biaiser les résultats dans les 2 sens, soit en les améliorant artificiellement, soit en les dégradant artificiellement. Un petit exemple ?

Imaginez une base dont toutes les tables sont en InnoDB. La base a une taille de 100 Go, le cache InnoDB (buffer pool) vaut 10Go. Pour avoir une idée du temps que va prendre une requête en production, vous remontez un environnement identique et après avoir démarré MySQL, vous exécutez votre requête plusieurs fois pour que le cache puisse se remplir et avoir ainsi un temps de réponse fiable. Vous obtenez les résultats suivants :

1er test : 4.5s
2nd test : 0.7s
3è test : 0.7s
4è test : 0.7s

Pourrez-vous dire qu’en production, votre cache étant bien évidemment chaud, la requête devrait s’exécuter en 0.7s ? Eh non ! Car le cache étant nettement plus petit que la taille de la base, il est tout à fait possible qu’au moment où vous exécutez votre requête en production, le cache ne contienne aucune donnée intéressante. Tout ce que vous pouvez dire, c’est que la requête va probablement mettre entre 0.7 et 4.5s pour s’exécuter en production.

Cette toute petite incursion dans le monde des caches montre qu’il n’est pas évident du tout de faire des tests de performances significatifs. Vous saurez maintenant vous méfier des benchmarks qui donnent des chiffres sans expliquer le protocole utilisé pour produire des résultats fiables…

Sécurité

Un des points clés cités par les partisans des routines stockées est la sécurité accrue : en effet, on peut contrôler les droits donnés aux utilisateurs plus finement et de manière plus flexible qu’avec le système de droits classiques via les commandes GRANT. Il suffit pour cela, au moment de la déclaration de la routine, d’ajouter la clause SQL SECURITY DEFINER 'user'@'host', qui permet d’exécuter la routine non pas avec les droits de l’utilisateur invoquant la routine mais avec les droits de l’utilisateur 'user'@'host'.

Par exemple, on peut décider de ne donner aucun droit via GRANT à un utilisateur pour une table t, mais lui laisser la possibilité de consulter cette table avec une routine getTData() et de modifier cette table avec une routine setTData(). On se rapproche ainsi du concept d’encapsulation des données que connaissent bien tous ceux qui ont l’habitude de travailler avec des langages objet.

Une autre possibilité intéressante des routines stockées est d’utiliser des requêtes préparées pour diminuer le risque d’injection SQL. Dans notre débat, cet argument ne constitue pas un avantage décisif dans la mesure où il est bien sûr possible de se servir des requêtes préparées sans routine stockée. A noter aussi que les requêtes préparées n’offrent pas une protection totale contre les injections SQL (c’est un bon sujet pour un autre article).

Il existe cependant quelques cas où une routine stockée peut créer des trous de sécurité. Ce sera le cas par exemple si vous utilisez des fonctions de cryptage dans vos routines : si quelqu’un peut accéder à la base, il pourra à la fois visualiser les données cryptées et la fonction de cryptage, facilitant le processus de décryptage des données. Si le cryptage avait été fait dans l’application, il faudrait réussir à avoir accès à la base de données et au code applicatif pour obtenir la même information.

Performance

C’est peut-être le sujet le plus intéressant sur les routines stockées car vous trouverez des exemples qui vous montreront tous les cas de figure possibles, de ceux qui ont gagné 200% de performance en écrivant une routine à ceux qui ont gagné 200% de performance en remplaçant les routines par du code applicatif. Pour bien comprendre pourquoi un tel fossé peut exister, il faut garder à l’esprit les quelques points suivants qui sont parfois contradictoires :

• exécuter une routine stockée économise du trafic réseau car toutes les requêtes internes à la routine n’ont pas à être transmises du client au serveur
• le plan d’exécution de la routine est mis en cache, ce qui est intéressant si on doit appeler plusieurs fois la même procédure (hors routines, le plan d’exécution est calculé à chaque passage d’une requête qui ne se trouve pas dans le cache de requêtes). Cependant, cette mise en cache se fait par connexion, ce qui peut gâcher des ressources et être peu efficace si de nombreuses connexions n’exécutent qu’une seule fois la même routine.
• le langage est vraiment simpliste par rapport à un vrai langage de programmation rendant difficile par exemple les manipulations avancées sur les chaînes de caractères, beaucoup de constructions se révèlent très lentes
• exécuter des routines stockées revient à décharger le serveur d’applications (ou le serveur web) et à charger le serveur de base de données, or la scalabilité de la base de données est plus difficile à assurer que celle d’un serveur d’applications

Ces quelques règles très simples vont vous donner une bonne indication sur les cas où les routines seront bénéfiques et sur les cas où il vaut mieux les éviter. Par exemple, si vous devez exécuter des requêtes très simples, le temps passé à la communication entre le client et le serveur devient non négligeable dans le temps total d’exécution de la requête. De même pour le temps passé pour l’optimisation. Avec une routine stockée, la communication client-serveur disparaît et comme le plan d’exécution est mis en cache, l’optimisation n’est faite qu’une seule fois.

On peut vérifier ces hypothèses dans le cas d’une table qu’on souhaite remplir avec un jeu de données de test :

CREATE TABLE t (
id int(11) NOT NULL AUTO_INCREMENT,
col1 varchar(10) DEFAULT NULL,
col2 int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;


Une procédure stockée permettant de remplir la table pourrait être la suivante :

DELIMITER $$

DELIMITER $$

CREATE DEFINER=`root`@`localhost` PROCEDURE `gen_table`(IN total INT)
BEGIN
   DECLARE i INT DEFAULT 0;
   WHILE i < total DO
     INSERT INTO t (col1,col2) VALUES ('aaaa',i*2+1);
     SET i = i+1;
   END WHILE;
END

et un programme PHP réalisant la même opération pourrait être :

<?php

$dbh = mysqli_connect('localhost','root','','test');

for($i=0;$i<$argv[1];$i++){

   $sql = "INSERT INTO t (col1,col2) VALUES ('aaaa',$i*2+1)";

   $dbh->query($sql) or die(mysqli_error($dbh));
}

?>


En cherchant à insérer 100 000 enregistrements dans la table par chacune des méthodes, j’obtiens les temps d’exécution suivants :

• procédure stockée : 4,48s
• programme PHP : 9,67s

Je vous laisse imaginer un exemple basé sur des calculs un peu compliqués, et qui tournerait à l’avantage du programme PHP…

Débogage

Voici bien un point pour lequel les routines stockées MySQL sont très faibles : rien, absolument rien n’est prévu pour vous aider à comprendre pourquoi une routine stockée est lente ou pourquoi le comportement observé n’est pas celui que vous attendiez. Pire, si vous activez le general_log pour essayer de voir toutes les requêtes qui sont faites par votre routine, vous ne verrez rien : en effet, seul l’appel à la routine sera stocké.

Conclusion

Alors, pour ou contre les routines stockées ? Comme j’espère vous l’avoir montré dans cet article, le tableau est loin d’être tout blanc ou tout noir. D’autant plus qu’il vous faudra également prendre en compte dans vos sauvegardes le fait d’utiliser des routines stockées et que les interactions entre réplication et routines stockées (si vous avez mis en place la réplication) sont loin d’être simples à gérer.

Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils sont capables de traiter par seconde (IOPS).

Comparés aux processeurs actuels capables de prendre plusieurs milliards de décisions par seconde (Ghz) et aux mémoires vives dont les temps d’accès se mesurent en nanosecondes, le temps d’accès d’un disque dur se compte encore en millisecondes… Difficile de lutter contre des éléments purement électroniques quand on est constitué d’éléments mécaniques en mouvement (têtes de lecture, plateaux…).

Afin d’avoir recours le moins possible aux disques, l’utilisation des index est une première étape qu’on complètera par différents mécanismes de caching afin de limiter encore davantage les accès à ce support et éviter ainsi que le disque ne constitue un goulet d’étranglement (« I/O bound »).

Outre ces mécanismes, la technologie SSD pourrait bien à l’avenir changer la donne.

Les SSD, littéralement Solid-State Drives (ou Disk par abus de langage), ne sont pas des disques mais des unités de stockage constituées de mémoire flash (persistante).

Au vu des benchmarks les concernant, il y’a fort à parier que les SSD seront de plus en plus d’actualité dans les mois qui viennent.
Ces benchmarks sont unanimes sur un point : les SSD obtiennent d’excellentes performances lors des random read, laissant loin derrière les disques « classiques ». Grosse ombre au tableau néanmoins : les tests effectués sur des random write ne sont pas aussi concluants. Pourquoi ?

Sur un disque classique un « random read » entraîne (du plus couteux au moins couteux) :
- le déplacement de la tête de lecture/écriture sur la bonne piste (« seek time »)
- une fois la tête sur la bonne piste, il faut encore repérer sur celle-ci le bloc secteur demandé (« rotational latency »)
- la lecture et la transmission de la donnée vers le système.

Avec un SSD, le même « random read » est beaucoup plus rapide : pas de tête de lecture à déplacer ni d’attente liée à la rotation d’un plateau. Conclusion, comptez environ 5 ms de temps d’accès à un secteur particulier pour un disque performant et environ 0.15 ms pour un SSD.

En revanche, lors d’une écriture, le SSD est par conception beaucoup plus lent qu’en lecture : la « préparation » obligatoire de l’importante zone dédiée à l’écriture (« erase block ») et un ensemble d’écritures spécifique à cette technologie pénalisent les performances.

Face à ce problème connu, des parades logicielles voient le jour et la plupart des constructeurs de SSD proposeront sûrement leur propre solution dans les mois à venir. Actuellement la technologie MFT (Managed Flash Technology) offre déjà de grandes améliorations (cf lien « benchmarks » ci-dessus, 3ème graphique). Les performances obtenues sont sensiblement égales lors des random read par rapport aux SSD classiques mais les résultats sont 30x supérieurs en random write par rapport aux SSD et 15x supérieurs aux disque durs.

Enfin, un autre signe que le SSD est très certainement une technologie d’avenir : un des plus récents moteurs pour MySQL, PBXT, est conçu pour fonctionner avec les SSD (pdf).

Pour résumer, concernant les SSD :

Avantages :
- Très rapide en random read
- Peu sensible à la fragmentation des fichiers : performances constantes.
- Fiabilité supérieure au HD (pas d’éléments mécaniques en mouvement)

Inconvénients des SSD :
- Prix
- Capacités en deça des disques actuels
- Durée de vie plus courte qu’un disque (nombres de cycles d’écriture limités)

Améliorations attendues (et en cours) :
- Chute des prix
- Augmentation des performances en écriture
- Augmentation de la capacité
- Meilleure répartition des écritures sur le support (augmentation du nombre de cycles écritures / durée de vie)

Si cette rapide présentation des SSD a aiguisé votre curiosité, voici quelques pistes pour aller plus loin :
- Le blog de Kevin Burton.
- La rubrique SSD sur Wikipédia (notamment les références en bas de page).

Il est conseillé en général de dédier un disque pour ces fichiers car beaucoup d’écriture entraîne une baisse de vos performances. Dans le cas qui nous intéresse, l’activité du CPU m’a très étonné. En effet jusqu’à 60% du temps CPU étaient utilisé par ‘USER’ juste en activant la réplication.

Suite à cela j’ai décidé avec mon ami Laurent de faire un peu de profiling… sommes nous un peu DBCSI? (comprenez database crime scene investigators ) Pour cela un outil intéressant est oprofile.

Pour tester ça, nous avons un DELL 2850 sous RHEL4 1 disque (hélas) et 2Go de RAM. Le programme de test à été exécuté pendant 30 minutes, et voila les résultats surprenant.

• Avec binlog

Profiling through timer interrupt
samples % image name symbol name
1680924 47.9708 /lib64/tls/libc-2.3.4.so __ctype_toupper_loc
1651101 47.1197 /usr/libexec/mysqld dict_create_foreign_constraints_low
54986 1.5692 /usr/libexec/mysqld yylex(void*, void*)
9083 0.2592 /usr/libexec/mysqld __do_global_ctors_aux
8541 0.2437 /usr/libexec/mysqld buf_pool_init
8284 0.2364 /lib64/tls/libc-2.3.4.so memcpy
5918 0.1689 /usr/libexec/mysqld my_snprintf_ucs2
4934 0.1408 /usr/libexec/mysqld log_buffer_flush_to_disk
4640 0.1324 /usr/libexec/mysqld my_strntod_ucs2
4268 0.1218 /usr/libexec/mysqld MD5Transform
3650 0.1042 /usr/libexec/mysqld my_parse_charset_xml

• Sans binlog

Profiling through timer interrupt
samples % image name symbol name
34847 9.7094 /usr/libexec/mysqld __do_global_ctors_aux
30416 8.4748 /lib64/tls/libc-2.3.4.so memcpy
30041 8.3703 /usr/libexec/mysqld buf_pool_init
20615 5.7439 /usr/libexec/mysqld my_snprintf_ucs2
17065 4.7548 /usr/libexec/mysqld my_strntod_ucs2
16656 4.6408 /usr/libexec/mysqld log_buffer_flush_to_disk
14908 4.1538 /usr/libexec/mysqld dict_create_foreign_constraints_low
9154 2.5506 /lib64/tls/libpthread-2.3.4.so pthread_mutex_trylock
8354 2.3277 /lib64/tls/libc-2.3.4.so __ctype_toupper_loc
8216 2.2892 /lib64/tls/libpthread-2.3.4.so pthread_mutex_unlock
5347 1.4898 /usr/lib/debug/lib/modules/2.6.9-22.ELsmp/vmlinux copy_user_generic
3380 0.9418 /usr/libexec/mysqld buf_flush_try_page

On remarque que lorsque les logs binaires sont activés, beaucoup de temps CPU est utilisé par cette fonction « dict_create_foreign_constraints_low ». Ce qui très étrange, car elle est supposé être utilisé lorsque d’une modification de DDL (création de tables,…) pour effectuer des vérifications sur les clés étrangères. Et sur cette application, même si nous sommes en InnoDB, il n’y en a aucune.

Des que nous aurons un peu de temps devant nous, nous referons le test sous MySQL 5.0.