Quelles sont les performances des différentes méthodes d'accès ? - Conseil sur la base de données MySQL
Conseil sur la base de données MySQL
Quelles sont les performances des différentes méthodes d'accès ?
Depuis PHP, il existe différentes manières de se connecter à une base de données MySQL et d'y rechercher des données.
On peut ainsi utiliser différents API PHP comme mysql, mysqli ou PDO (PHP Data Objects).
Le manuel PHP recommande d'ailleurs d'utiliser l'extension mysqli pour les versions PHP supérieures ou égales à la 4.1.3.
L'interface PDO permet de faire abstraction de la base utilisée en utilisant les mêmes commandes quelque soit le type de base de données. L'inconvénient de PDO réside dans sa non prise en charge des fonctionnalités avancées de MySQL, par exemple executer des requêtes multiples.
Pour comparer les fonctionnalités et les recommandations de la documentation officielle, voir le site officiel de PHP répertoriant les différents supports (section "Comparaison des fonctionnalités").
Doctrine est un framework de mapping objet-relationnel pour PHP. Il est principalement utilisé dans le framework Symfony à la place de Propel. Il permet aussi d'accéder à une base de données et de récupérer des enregistrements.
Bien que chaque méthode ait des possibilités plus étendues, la connexion à une base, la recherche et le retour d'un enregistrement sont ici les critères de réussites retenues.
Les différentes possibilités testées ici sont donc :
- Mysql
- Mysqli
- PDO
- Doctrine
Le traitement des résultats est testé avec l'utilisation de 2 méthodes : avec un objet ou avec un tableau.
Pour le test avec Doctrine, la méthode "find()" est aussi analysée. Le résultat est retourné sous la forme d'un objet.
Les recherches s'effectuent sur une table TEST contenant 2 champs : un champ TEST_id de type INTEGER auto incrémenté et un champ TEST_data de type VARCHAR(50) contenant une chaîne de caractères [a-z0-9] de 8 caractères de longueur en moyenne.
Pour différencier les temps de requêtes et les temps de connexion à la base, 2 mesures ont été effectuées pour chaque test : une comprenant uniquement le temps de traitement de la requête et une autre comprenant la connexion plus la recherche.
Les requêtes retournaient uniquement le champ TEST_data après la recherche sur le champ TEST_id. Pour diminuer l'impact de la création d'un entier de recherche aléatoire, un tableau de recherche est créé avant la connexion à la base et n'est pas pris en compte dans la mesure.
Pour niveler les résultats et éliminer les pics d'activités externes, chaque configuration a été testée 10 000 fois.
Les mesures de temps sont effectuées selon l'ordre suivant :
création du tableau des identifiants recherchés;
mesure du temps 1;
connexion à la base de données;
requête;
traitement du résultat et affichage;
mesure du temps 2;
Ces résultats sont représentés par les barres rouges. Pour les mesures de durées de la requête uniquement (les barres vertes sur les graphiques), la "mesure du temps 1" intervient juste après la connexion à la base de données.
Le temps de connexion à la base de données est ici mesuré sans requête supplémentaire.
Pour plus de clarté, le graphique précédent a été restreint à un intervalle comprit entre 0 et 1 ms. Il met en évidence les temps de connexion très proches suivant les méthodes mysql, mysqli et PDO. L'ORM Doctrine demande ici 30,5 ms en partie dû au chargement de l'autoload.
L'ORM Doctrine se révèle être la méthode de connexion la plus lente. Malgré ce temps initial supplémentaire, il est intéressant de voir dans les tests suivants si ce temps supplémentaire requis est compensé par un traitement plus rapide des requêtes.
On recherche ici 100 enregistrements uniques aléatoires parmi le million existant. Ceci permet d'évaluer les comportements des méthodes pendant les moments de charges plus importants.
La requête retournant un enregistrement aléatoire est :
"SELECT TEST_data FROM TEST WHERE TEST_id=".$i
Pour plus de clarté, le graphique précédent a été restreint à un intervalle comprit entre 0 et 60 ms. Il met en évidence les très temps proches suivant les méthodes mysql, mysqli et PDO. L'ORM Doctrine demande ici presque 1 seconde.
L'ORM Doctrine se retrouve encore une fois dernier en terme de performance quelque soit le traitement des données reçues. Le traitement des résultats sous forme de tableau au lieu d'un objet est plus rapide dans tous les case de figure.
On note aussi que la méthode find() trouve ici un intérêt de par sa simplicité d'écriture tout en n'empiétant pas sur les performances globales du script.
Les méthodes mysql, mysqli et PDO sont tout de même largement devant avec des gains d'un facteur 20.
Les temps de ces 3 méthodes sont à peu près équivalents bien que PDO et surtout mysqli prennent l'avantage sur mysql. L'écart maximum atteint 10 % ce qui peut aussi être mis sur le compte de facteurs extérieurs aux scripts testées (requêtes annexes, ...).
A la différence du test précédent, une seule requête est traitée ici mais avec cette fois un résultat différent puisqu'il comporte 100 enregistrements. Les temps de traitement et de transfert des données deviennent prépondérants avec la création d'un jeu de résultat plus lourd.
La méthode find() n'a pas pu être testée puisqu'elle ne retourne qu'un seul résultat.
La requête retournant 100 enregistrements à partir d'un enregistrement aléatoire est :
"SELECT TEST_data FROM TEST WHERE TEST_id=".$i." LIMIT 0,100"
Pour plus de clarté, le graphique précédent a été restreint à un intervalle comprit entre 0 et 4 ms. Ceci permet de comparer les différences entres les méthodes mysql, mysqli et PDO.
Les performances globales sont logiquement meilleures que dans le test précédent malgré la taille des résultats renvoyés. On retrouve ici les conclusions précédentes sur le traitement des résultats puisqu'un traitement sous forme d'objet requiert plus de ressources.
Comme le test précédent, les méthodes mysql, mysqli et PDO prennent nettement l'avantage sur Doctrine. Le rapport atteint ici un facteur 40.
Mysql se révèle être la méthode plus rapide quelque soit le traitement des résultats. PDO ressort être un peu plus lent que les autres méthodes. Cependant, les différences constatées n'atteignent pas 10 % et peuvent être attribuées à des facteurs extérieurs aux scripts exécutés (requêtes annexes sur le serveur, ...).
Indépendamment des temps de connexion à la base de données, l'ORM Doctrine, bien qu'offrant d'autres possibilités de gestion, se révèle très gourmand en ressource par rapport aux autres méthodes.
Bien que faible, on remarque quand même une amélioration du temps de réponse pour toutes les requêtes traitées sous forme de tableau et non d'objet. Les écarts ne sont pas significatifs mais passer d'un traitement sous forme d'objet à un traitement sous forme de tableau peut améliorer la vitesse de 5 %. Cet écart n'en est pas moins indéniable car constaté dans l'ensemble des tests effectués.
On peut ainsi utiliser différents API PHP comme mysql, mysqli ou PDO (PHP Data Objects).
Le manuel PHP recommande d'ailleurs d'utiliser l'extension mysqli pour les versions PHP supérieures ou égales à la 4.1.3.
L'interface PDO permet de faire abstraction de la base utilisée en utilisant les mêmes commandes quelque soit le type de base de données. L'inconvénient de PDO réside dans sa non prise en charge des fonctionnalités avancées de MySQL, par exemple executer des requêtes multiples.
Pour comparer les fonctionnalités et les recommandations de la documentation officielle, voir le site officiel de PHP répertoriant les différents supports (section "Comparaison des fonctionnalités").
Doctrine est un framework de mapping objet-relationnel pour PHP. Il est principalement utilisé dans le framework Symfony à la place de Propel. Il permet aussi d'accéder à une base de données et de récupérer des enregistrements.
Bien que chaque méthode ait des possibilités plus étendues, la connexion à une base, la recherche et le retour d'un enregistrement sont ici les critères de réussites retenues.
Les différentes possibilités testées ici sont donc :
- Mysql
- Mysqli
- PDO
- Doctrine
Le traitement des résultats est testé avec l'utilisation de 2 méthodes : avec un objet ou avec un tableau.
Pour le test avec Doctrine, la méthode "find()" est aussi analysée. Le résultat est retourné sous la forme d'un objet.
Protocole
Les recherches s'effectuent sur une table TEST contenant 2 champs : un champ TEST_id de type INTEGER auto incrémenté et un champ TEST_data de type VARCHAR(50) contenant une chaîne de caractères [a-z0-9] de 8 caractères de longueur en moyenne.
Pour différencier les temps de requêtes et les temps de connexion à la base, 2 mesures ont été effectuées pour chaque test : une comprenant uniquement le temps de traitement de la requête et une autre comprenant la connexion plus la recherche.
Les requêtes retournaient uniquement le champ TEST_data après la recherche sur le champ TEST_id. Pour diminuer l'impact de la création d'un entier de recherche aléatoire, un tableau de recherche est créé avant la connexion à la base et n'est pas pris en compte dans la mesure.
Pour niveler les résultats et éliminer les pics d'activités externes, chaque configuration a été testée 10 000 fois.
Les mesures de temps sont effectuées selon l'ordre suivant :
création du tableau des identifiants recherchés;
mesure du temps 1;
connexion à la base de données;
requête;
traitement du résultat et affichage;
mesure du temps 2;
Ces résultats sont représentés par les barres rouges. Pour les mesures de durées de la requête uniquement (les barres vertes sur les graphiques), la "mesure du temps 1" intervient juste après la connexion à la base de données.
Tests
1er test : temps de connexion à la base de données
Le temps de connexion à la base de données est ici mesuré sans requête supplémentaire.
Pour plus de clarté, le graphique précédent a été restreint à un intervalle comprit entre 0 et 1 ms. Il met en évidence les temps de connexion très proches suivant les méthodes mysql, mysqli et PDO. L'ORM Doctrine demande ici 30,5 ms en partie dû au chargement de l'autoload.
L'ORM Doctrine se révèle être la méthode de connexion la plus lente. Malgré ce temps initial supplémentaire, il est intéressant de voir dans les tests suivants si ce temps supplémentaire requis est compensé par un traitement plus rapide des requêtes.
2ème test : 100 recherches aléatoires d'un enregistrement
On recherche ici 100 enregistrements uniques aléatoires parmi le million existant. Ceci permet d'évaluer les comportements des méthodes pendant les moments de charges plus importants.
La requête retournant un enregistrement aléatoire est :
"SELECT TEST_data FROM TEST WHERE TEST_id=".$i
Pour plus de clarté, le graphique précédent a été restreint à un intervalle comprit entre 0 et 60 ms. Il met en évidence les très temps proches suivant les méthodes mysql, mysqli et PDO. L'ORM Doctrine demande ici presque 1 seconde.
L'ORM Doctrine se retrouve encore une fois dernier en terme de performance quelque soit le traitement des données reçues. Le traitement des résultats sous forme de tableau au lieu d'un objet est plus rapide dans tous les case de figure.
On note aussi que la méthode find() trouve ici un intérêt de par sa simplicité d'écriture tout en n'empiétant pas sur les performances globales du script.
Les méthodes mysql, mysqli et PDO sont tout de même largement devant avec des gains d'un facteur 20.
Les temps de ces 3 méthodes sont à peu près équivalents bien que PDO et surtout mysqli prennent l'avantage sur mysql. L'écart maximum atteint 10 % ce qui peut aussi être mis sur le compte de facteurs extérieurs aux scripts testées (requêtes annexes, ...).
3ème test : recherche de 100 enregistrements à partir d'un enregistrement aléatoire
A la différence du test précédent, une seule requête est traitée ici mais avec cette fois un résultat différent puisqu'il comporte 100 enregistrements. Les temps de traitement et de transfert des données deviennent prépondérants avec la création d'un jeu de résultat plus lourd.
La méthode find() n'a pas pu être testée puisqu'elle ne retourne qu'un seul résultat.
La requête retournant 100 enregistrements à partir d'un enregistrement aléatoire est :
"SELECT TEST_data FROM TEST WHERE TEST_id=".$i." LIMIT 0,100"
Pour plus de clarté, le graphique précédent a été restreint à un intervalle comprit entre 0 et 4 ms. Ceci permet de comparer les différences entres les méthodes mysql, mysqli et PDO.
Les performances globales sont logiquement meilleures que dans le test précédent malgré la taille des résultats renvoyés. On retrouve ici les conclusions précédentes sur le traitement des résultats puisqu'un traitement sous forme d'objet requiert plus de ressources.
Comme le test précédent, les méthodes mysql, mysqli et PDO prennent nettement l'avantage sur Doctrine. Le rapport atteint ici un facteur 40.
Mysql se révèle être la méthode plus rapide quelque soit le traitement des résultats. PDO ressort être un peu plus lent que les autres méthodes. Cependant, les différences constatées n'atteignent pas 10 % et peuvent être attribuées à des facteurs extérieurs aux scripts exécutés (requêtes annexes sur le serveur, ...).
Conclusion
Indépendamment des temps de connexion à la base de données, l'ORM Doctrine, bien qu'offrant d'autres possibilités de gestion, se révèle très gourmand en ressource par rapport aux autres méthodes.
Bien que faible, on remarque quand même une amélioration du temps de réponse pour toutes les requêtes traitées sous forme de tableau et non d'objet. Les écarts ne sont pas significatifs mais passer d'un traitement sous forme d'objet à un traitement sous forme de tableau peut améliorer la vitesse de 5 %. Cet écart n'en est pas moins indéniable car constaté dans l'ensemble des tests effectués.
Les autres astuces du même thème :
Quelle est la surcharge engendrée par une recherche texte ?
Quelles sont les performances des différentes méthodes d'accès ?
