Tests de performances de requêtes SQL

[Argorate]

Je vois pas qu'es ce que ça change de faire plusieurs fichiers à part étaler son code. Je préfère mes 4 pauvres fonction de 4 lignes chacune...
Cependant, je vous en prie, si vous avez linux, faite le test, on pourra comparer, ça ne sera que plus enrichissant

J'attends toujours le résultat de 100 000 boucles sur 100 000 enregistrements pour voir...
Les nouveaux chiffres que j'ai semble reflété la tendance et la différence entre les methodes est moindre par rapport au chiffres éroné que j'ai mis au début.
On en reparle quand j'ai fini.

Sinon je ne compte qu'une seul préparation de la requête, puisque tout l'intérêt d'une requête préparer c'est qu'une fois qu'elle l'est, plus besoin de la repréparer.

[php_addict]

en tout ca si quelqu'un fait un test fiable cela peut etre interessant

[Sephi-Chan]

Comme d'habitude, ce n'est pas parce que tu préfères que c'est mieux (en pratique, c'est souvent le contraire…).

En effectuant les tests à la chaîne comme tu le fais, tu ne permet pas à la machine de récupérer ses ressources.
En les executant dans des processus différents et à quelques secondes d'intervalle, tu mets chaque test sur un pied d'égalité.

Et pour les requêtes préparées, je ne suis pas d'accord. En pratique, dans tes pages, tu auras toujours :

$statement = $db->prepare($query);

$statement->execute();

Isoler la préparation n'est donc pas pertinent.


De plus, tes tests occultent totalement l'avantage des requêtes préparées : l'échappement automatique.
Il faut donc que tu fasses des tests avec le mysql_real_escape_string (et équivalent avec PDO) quand tu n'utilises pas de requête préparée.

En résumé, si tu ne rends pas ta procédure plus juste, ce n'est pas la peine de publier de résultats : tu risques d'induire les gens en erreur, à commencer par toi-même.


Sephi-Chan

[Argorate]

Je ne vois pas de quel ressource tu parles? Lorsqu'une méthode est terminer, l'autre prend la suite, et je te rassure j'ai assez de RAM pour les 4, quand au CPU, je ne pense pas qu'un double cœur aura du mal en local, d'autant plus que je limite mes taches parallèle. (il n'atteint que 75% de charges là...)
Le but est d'avoir un ordre de grandeur, pas la valeur exacte au 10ème chiffre après la virgule :p
Sinon le fait d'avoir du traitement en plus en utilisant mysql_real_escape_string() ne m'intéresse absolument pas dans ce test, je cherche la performance. L'aspect sécurité ne viens qu'après.

Par contre je suis étonné pour les requêtes préparer, les requêtes préparer sont supposé allez dans le cache non? S'il le faut je rectifierais ce point là, mais j'aurais aimé comprendre pourquoi avant ^^

[Sephi-Chan]

Si tu veux n'en faire qu'à ta tête, libre à toi. Par contre, indique bien en haut du sujet que ces tests ne sont pas fiables, de façon à ce qu'aucun innocent ne prenne tes données au sérieux.

Le but est d'avoir un ordre de grandeur, pas la valeur exacte au 10ème chiffre après la virgule :p

Methode mysql : 1.0119338440895 ms, soit : 0.0010119338440895 secondes (ou encore 1.6865564068158 min) [101.19338440895 secondes pour 100000]

Tu es très cohérent. iffle:


Pour les requêtes préparées, je ne fais que te donner le cas d'utilisation. Après, peut-être que MySQL n'effectue qu'une fois la préparation à proprement parler, mais quand quelqu'un écrit un script PHP, la méthode de préparation (prepare) est appelée avant celle d'exécution (execute).

Enfin bref, comment transformer un sujet potentiellement intéressant en une vaste fumisterie inutile…


Sephi-Chan

[Argorate]

Je vais faire un test en rajoutant le prépare a chaque itération au lieu d'une fois, on verra bien la différence...
Je pense que je vais arrêter mon test en cours de 100 000 boucle là, on dirait que ça prend des heures, ça me gène pour effectuer d'autres tests.
Pour ce qui est des chiffres, j'utilise microtime() et je laisse le chiffre en entier plutôt que d'arrondir, c'est peut être se que tu souhaites?

[Sephi-Chan]

En isolant chaque test dans un script, tu aurais pu les lancer séparément et ainsi mieux maîtriser la durée pendant laquelle ça monopolise ta machine. De plus, tu aurais eu la garantie qu'aucune fuite mémoire ne vienne fausser ton test (car ce sont des choses qui arrivent souvent dans les langages de scripts, plus adaptés à une courte durée de vie).

Je ne souhaite rien du tout : je me suis désintéressé du sujet dès que j'ai vu que tu ne voulais pas améliorer la pertinence de tes tests (ce qui ne m'a pas beaucoup étonné de ta part, d'ailleurs). Je soulignais simplement l'incohérence de ton propos. Si tu voulais un ordre de grandeur : la durée en milliseconde avec deux chiffres après la virgule suffirait. Exprimer la durée en seconde et en minutes est inutile.


Sephi-Chan

[Argorate]

Bon voilà, j'ai mis a jour les quelques résultats que j'ai eu le temps de refaire sur le premier topic. Un peu la flemme d'en faire plus là (faut dire qu'on m'encourage tellement ^^)
Globalement, les requêtes préparer lorsqu'il y a des paramètres externe semble plus rapide. Ce qui m'embête c'est la net baisse de performance des requêtes préparer (avec mysql_querry notamment) à chaque itération... Ça veux dire que ça ne vaut pas le coup, mais du coup mysql_querry contre pdo se débrouille plutôt bien, même par rapport aux requêtes pdo préparer... Donc je ne sais pas trop quel conclusion en tirer...

[Nosrehl]

Bin Argorate c'est une bonne initiative tes tests mais écoute Sephi et fais-nous des tests significatifs, pas des tests où on se dit mouais bizarre avant de retourner à nos moutons.
T'as déjà fais le gros du travail en plus, c'est dommage de massacrer ton travail en ne tenant pas compte des remarques.

[niahoo]

Je vais faire un test en rajoutant le prépare a chaque itération au lieu d'une fois, on verra bien la différence...
Je pense que je vais arrêter mon test en cours de 100 000 boucle là, on dirait que ça prend des heures, ça me gène pour effectuer d'autres tests.
Pour ce qui est des chiffres, j'utilise microtime() et je laisse le chiffre en entier plutôt que d'arrondir, c'est peut être se que tu souhaites?

Tu n'as pas compris ce que je disais. mettre un prepare a chaque iteration c'est idiot.