Connexions max pour le MySQL, comment, quoi, etc ?

[Ter Rowan]

y a quand même un truc qui me gêne dans tout ça :

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

[Shivaan Keldon]

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

[Ter Rowan]

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
mysql_connect
/* 1010 lignes de code */
mysql_close
?>

pourquoi ne pas faire :

Code :

<?php
mysql_connect
/* 1010 lignes de code */

                 /***** mysql_close *******/
?>

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)

[Shivaan Keldon]

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

[Cartman34]

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.

Tout comme en dérivant un peu du sujet, il est nettement préférable de faire :
if (is_array($tableau) === true)
plutôt que :
if (is_array($tableau))

tout comme il est nettement plus intéressant de faire === que ==, on se rend compte quand on se met à utiliser === au combien on était loin de ce que l'on pensait dans pas mal de cas. Et toutes ces recommandations permettent de cloisonner grandement notre application et ainsi éviter autant que faire se peu, des bugs étranges.

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.

[Thumsoul]

En lisant le dernier post d'oxman, une question me vient à l'esprit : c'est quoi la différence entre === et == ?

Merci

[Cartman34]

Avec === la comparaison est plus stricte car le type est aussi pris en compte.

[Thumsoul]

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 ?)

[Cartman34]

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.

[z3d]

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