Connexions max pour le MySQL, comment, quoi, etc ? - 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 : Connexions max pour le MySQL, comment, quoi, etc ? (/showthread.php?tid=2746) |
RE: Connexions max pour le MySQL, comment, quoi, etc ? - Ter Rowan - 17-07-2008 y a quand même un truc qui me gêne dans tout ça : Citation :L'utilisation de mysql_close() n'est pas habituellement nécessaire, puisque les connexions non persistantes ouverts sont automatiquement fermées à la fin l'exécution du script. Voyez aussi libérer des ressources.(source) en fait ce que je me demande c'est dans quel cas il y a un intérêt pour optimiser ses ressources machines de fermer une connexion avant la fin si dans un script j'ai 100 lignes de code php derrière la dernière utilisation de la base de données y a t il un intérêt ? si dans un script j'ai 1000 lignes de code php derrière la dernière utilisation de la base de données y a t il un intérêt ? Au bout de combien de micro seconde de traitement ça vaut le coup de lancer cet ordre (en dehors du côté propre théorique, j'ouvre donc je ferme) en effet le risque à fermer une connexion (je crois même l'avoir lu dans le commentaire d'un gars) c'est si on ne la ferme pas au bon endroit, de la rouvrir un peu plus tard pour une nouvelle requête certes c'est mal programmer que de faire cela mais l'homme est faillible, le développeur sous notepad encore plus :p RE: Connexions max pour le MySQL, comment, quoi, etc ? - Shivaan Keldon - 18-07-2008 je suis assez d'accord avec oxman je ferai une comparaison avec le néon. à l'utilisation, il consomme moins qu'une ampoule. mais par contre à l'allumage, il consomme bien plus c'est pareil ici. il vaut mieux garder une connexion ouverte jusqu'au bout plutôt que de la fermer pour la rouvrir à l'instruction suivante. après, si dans les 100 ou 1000 lignes de codes qui suivent, il n'y a plus aucune interaction avec la base, et il n'y en aura plus jusqu'à la fin du script, il vaut mieux la fermer RE: Connexions max pour le MySQL, comment, quoi, etc ? - Ter Rowan - 18-07-2008 yop mais en relisant ma question je me suis aperçu que j'avais mal exprimé une de mes interrogations donc plutôt qu'un grand discours si je reprends le code d'oxman: Code : <?php pourquoi ne pas faire : Code : <?php grosso modo n'utiliser mysql_close que si on compte fermer puis rouvrir (parce que jesais pas quoi de très intelligent) et laisser se débrouiller php sinon (cf citation de mon précédent message) RE: Connexions max pour le MySQL, comment, quoi, etc ? - Shivaan Keldon - 18-07-2008 je pense qu'il faut faire la différence entre théorie et pratique en théorie, Php ferme toutes les connexions à la fin d'une page, tout comme il supprime de sa mémoire toute les variables (sauf les sessions, évidemment, puisqu'elles sont faites pour ça) en pratique, est-ce que ça se passe réellement comme ça ? j'en doute un peu. car comme l'a dit oxman, si la charge du serveur est trop grande, et surtout selon sa qualité (genre un serveur IIS sous windows sur un p2 à 800Mhz 156Mo), il se peut que le serveur s'embrouille et oublie de faire certaines choses. moi perso, je préfère ne pas parier là dessus et fermer moi même les connexions, et toujours mettre mes variables à null dès que j'en ai plus besoin. et pour répondre à oxman, tu as peut-être raison, mais je suis pas convaincu à 100%. il faudrait trouver quelqu'un qui a vécu le problème, ou déjà fait des tests de montée en charge. car pour moi, une connexion à mysql est très légère. en tout cas, bien plus qu'une vers oracle à voir... RE: Connexions max pour le MySQL, comment, quoi, etc ? - Cartman34 - 18-07-2008 Shivaan Keldon a écrit :en théorie, Php ferme toutes les connexions à la fin d'une page, tout comme il supprime de sa mémoire toute les variables (sauf les sessions, évidemment, puisqu'elles sont faites pour ça)Laisse moi te corriger stp: Les variables sessions sont bien supprimées de la mémoire mais elles sont stockées dans un fichier. oxman a écrit :Tout comme en dérivant un peu du sujet, il est nettement préférable de faire :Je pense que c'est 2 fois plus long pour PHP donc non ce n'est pas préférable, c'est juste à utiliser avec attention car les betises arrivent vite comme if($_POST) ce qui n'est pas correcte. RE: Connexions max pour le MySQL, comment, quoi, etc ? - Thumsoul - 18-07-2008 En lisant le dernier post d'oxman, une question me vient à l'esprit : c'est quoi la différence entre === et == ? Merci RE: Connexions max pour le MySQL, comment, quoi, etc ? - Cartman34 - 18-07-2008 Avec === la comparaison est plus stricte car le type est aussi pris en compte. RE: Connexions max pour le MySQL, comment, quoi, etc ? - Thumsoul - 18-07-2008 Ah ok, merci pour la précision. Ca ne ralentit pas trop le script ? (J'veux dire, si on a 50 conditions sur la page, ça gêne pas de tout passer en triple égal ?) RE: Connexions max pour le MySQL, comment, quoi, etc ? - Cartman34 - 18-07-2008 Je ne pense pas que cela est beaucoup d'effet, en effet, il évrifie dans tous les cas l'égalité alors il est pas à ca près(la vitesse d'une vérif est assez grande). Cela peut etre très utile mais en PHP, il ne faut faire que le strict minimum, ne vérifiez le type que si vous en avez vraiment besoin, ne faites une condition que si vous en avez déjà besoin. Si je marque if(1) ou if(true), PHP ne va faire aucune vérification car les 2 retournent vraies. Par contre if(1 === true) sera plus long que if(1) car il y a une condition à vérifier. Cependant, ce ne sont que des principes car ca se joue à des millionièmes de secondes...par de quoi perturber des foules. RE: Connexions max pour le MySQL, comment, quoi, etc ? - z3d - 19-07-2008 Alors pour répondre clairement entre == et ===, il est plus rapide pour PHP d'évaluer le === que le ==. Pour une raison simple, === ne tentera pas de transtyper la variable pour l'évaluer, il l'évaluera tel quel. Ensuite comme le dit Oxman, l'explicite est meilleur que l'implicite. Dans tout langage l'implicite est de mise mais on expliquera assez jamais qu'il ne faut jamais l'étre |