Tests de performances de requêtes SQL - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : Tests de performances de requêtes SQL (/showthread.php?tid=5338) |
RE: [Test Performence] Requetes SQL - Argorate - 31-03-2011 (31-03-2011, 02:38 PM)Sephi-Chan a écrit : Et pour les requêtes préparées, je ne suis pas d'accord. En pratique, dans tes pages, tu auras toujours :Faudrait voir a vous accordez les violons les jeunes... iffle: RE: Tests de performances de requêtes SQL - niahoo - 31-03-2011 et bien moi je disais ça par rapport à un test sur 100 000 fois la même requête. Il est cohérent de ne la préparer qu'une seule fois. Il est aussi cohérent de ne la préparer qu'une seule fois et de l'exécuter avec un tableau de bindings différent à chaque coup et en face d'utiliser mysql query avec une concaténation de valeurs différentes dans la requête. Mais si le test portait uniquement sur l'exécution d'une requête unique, alors oui tu fais prepare() à chaque fois. Comme je le disais, ce test n'est pas clair RE: Tests de performances de requêtes SQL - srm - 01-04-2011 Il ne faut faire qu'un seul prepare oui, mais inclure le temps qu'a pris ce prepare dans les calculs, mais sur 10 0000 requêtes il est insignifiant J'aimerais bien que tu pousses le test avec PostgreSQL aussi ^^ RE: Tests de performances de requêtes SQL - Sephi-Chan - 01-04-2011 Quand vous dites qu'on ne prépare la requête qu'une fois, c'est une fois par script, non ? Car en pratique, chaque fois que j'ai vu des requêtes préparées, j'ai toujours vu le cas du prepare appelé avant le execute, et donc autant de preparation que d'exécution. Quels exemples pouvez-vous fournir de cas où l'on prépare une fois la requête et on l'exécute de nombreuses fois ? Notamment dans le cas de requêtes type SELECT, car je l'imagine assez bien pour une succession de requêtes d'insertion (histoire de préparer une fois puis d'insérer plusieurs valeur sans se soucier de l'échappement). Sephi-Chan RE: Tests de performances de requêtes SQL - srm - 01-04-2011 Il y en a très peu, c'est surtout pour du bulk opération. Donc oui on la voit quasiment tout le temps juste au dessus du execute. Mais si tu avais 10 ou 20 execute à faire dans une boucle tu mettrais le prepare dedans ? Non au dessus RE: Tests de performances de requêtes SQL - Sephi-Chan - 01-04-2011 Ok, c'est bien ce que je pensais. Mais du coup, le test est plus réaliste avec le prepare dedans, puisque dans la grande majorité des cas, on a pas affaire à des traitements de lots. Sephi-Chan RE: Tests de performances de requêtes SQL - niahoo - 01-04-2011 C'est ce que je disais, si tu veux mesurer la performance sur une seule requête tu mets le prepare dans la boucle. peut-être faut il également détruire l'objet car il y a un cache je crois. RE: Tests de performances de requêtes SQL - srm - 01-04-2011 Donc on compare une requête du type "normal" surtout prévu pour des envois simple et une requête du type "prepare" surtout prévu pour des envois multiples. Ok. RE: Tests de performances de requêtes SQL - niahoo - 01-04-2011 C'est pour ça qu'un test dans ces conditions ne me paraissait pas clair. Mais effectivement il était plus intellignent de bannir le prepare complètement. Car PDO permet de faire des requêtes sans prepare() via query() et exec() comme vous le savez tous RE: Tests de performances de requêtes SQL - srm - 01-04-2011 De toute façon, j'utilise toujours prepare, car je n'ai pas un besoin accru de performances 99% du temps. Et au moins tu as un truc clean et très sécurisé, aucune injection possible |