Archive pour le mot-clef ‘benchmarks’

A quoi sert SQL_NO_CACHE ?

Mardi 29 mars 2011

Lorsqu’on essaie d’améliorer une requête, que ce soit en modifiant le plan d’exécution ou en réécrivant la requête, on finit par choisir la variante dont le temps d’exécution est le plus faible. Encore faut-il que ce temps d’exécution ne soit pas falsifié par un quelconque cache. En cherchant comment désactiver les caches de MySQL, vous avez certainement trouvé la directive SQL_NO_CACHE. Cet article va faire le point sur ce que fait cette directive, mais également sur ce qu’elle ne fait pas.
Lire le reste de cet article »

Pour ou contre les procédures et fonctions stockées ?

Mercredi 8 décembre 2010

Faut-il oui ou non utiliser des procédures ou fonctions stockées avec MySQL ? Le question a souvent été soulevée et donne lieu à chaque fois à de vifs échanges entre pro et anti. Cet article vous propose une approche différente : se focaliser sur quelques points particuliers (sécurité, performance, débogage) et donner les avantages et inconvénients de l’utilisation des routines stockées. Avec ces éléments en main, vous pourrez décider par vous-même si les routines stockées sont pertinentes pour votre application. Lire le reste de cet article »

Les SSD (Solid-State Drive) : une technologie d’avenir pour nos SGBD ?

Mardi 13 mai 2008

Modifier une petite ligne dans le fichier de configuration de son SGBD et obtenir les performances souhaitées, c’est possible… si vous êtes chanceux. La performance globale d’un SGBD repose en effet sur un ensemble de briques, logicielles ou matérielles, qui une fois empilées correctement forment un ensemble cohérent (et performant) : la seule étape du fichier de configuration ne suffit pas.

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…).

Lire le reste de cet article »

Réplication et Log binaires

Vendredi 6 avril 2007

Qui n’a jamais utilisé MySQL sans la réplication? La réplication permet à votre application de supporter un nombre de lecture beaucoup plus important. Les updates se font sur une base de donnée « maître » (master) et sont ensuite répliquées sur plusieurs « esclaves » (slaves). Le maître n’a pas à supporter les requêtes venant de clients qui sont gérées par les esclaves. Un autre jour je rentrerai plus en détails la dessus mais en résumé, le maître écrit dans des fichiers toutes les requêtes qui ont modifié ses informations (insert, update et delete). Les slaves viennent à leur tour récupérer ces fichiers (binary logs) et les « copie » localement (relay logs) avant de les rejouer.

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.
Lire le reste de cet article »