Utilité d'une deconnexion SQL

[comparef]

Bonjour,

J'ai l'habitude de mettre un "mysql_close($cbdd);" afin de me deconnecter de la base de donnée en bas de mes pages ou apres certaines requetes.

Je me pose donc la question de l'utilité de faire cela systematiquement apres avoir ouvert une connexion a une base de donnée ?

Je suppose que cela doit etre important du point de vue de la securité, peut etre aussi au niveau de l'optimisation des ressources utilisés lorsqu'on se connecte a une base de donnée ?

Merci d'avance pour votre reponse,
Robin

 

[Szarah]

La durée de connexion doit être aussi courte que possible, ce n'est pas seulement une question de sécurité mais de nombre d'utilisateurs simultanés.

- Tu ouvres la base
- tu l'utilises
- tu la fermes aussi vite que possible.

 

[Grantome]

Fermer une connexion à la fin de la page ne sert à rien, parceque c'est fait automatiquement.

Par contre, pour imager ce que dit Szarah :

Header
Préparation des requête SQL = ...
Connexion SQL
Res = ...
Fermeture SQL
Traitement des Res
Affichage

 

[TOMHTML]

oui il vaut mieux la fermer car si...
-tu ouvre ta connexion
-tu fais ta requête
-tu l'utilise
- tu fais plein d'autres trucs après mais qui n'ont plus rien à voir avec sql
-et dès que c la fin de page tu coupe ta connexion

et bien le point n°4 fait que tu as plus de chance de faire sauter la BD à cause des connexions simultannées.
donc entre le n°3 et n°4 : CLOSE

 

[comparef]

OK, merci pour vos reponse,

Bonne continuation

Robin

 

[comparef]

Bonjour,

Mon probleme étant les bug liés au "too many connexion", je me posai la question suivante, ce too many connexion est-il due a trop de connexions (mysql_connect(serveur,user,passwd)) ou bien aussi a trop de requetes (mysql_db_query()) ?

Et au sujet de ce que vous m'avez dit dans les messages ci-dessus, il m'arrive de faire des traitement assez long, mais d'avoir de nouveau besoin de la base de donnée apres, est-il préférable de fermer la connection durant ce long traitement et de la réouvrir ensuite ?
Cela ferait :

-Connexion BDD (mysql_connect(serveur,user,passwd))
-Extractions et requetes diverse
-Deconnexion de la BDD (mysql_close(bdd))
-TRAITEMENT
-Connexion BDD (mysql_connect(serveur,user,passwd))
-Extractions et requetes diverse
-Deconnexion de la BDD (mysql_close(bdd))

Lorsque c'est possible je suppose qu'il faut faire tout ce qui est lié a la BDD au meme endroit, mais il arrive que cela ne soit pas possible.

Merci d'avance pour vos reponses,
Robin

 

[Grantome]

Bah si c'est possible,

-Connexion BDD (mysql_connect(serveur,user,passwd))
-Extractions et requetes diverse
- petit TRAITEMENT
-Extractions et requetes dues au petit traitement
-Deconnexion de la BDD (mysql_close(bdd))
- Traitement

 

[TOMHTML]

il demande pas si c'est possible, mais ce qui est préférable.

Mais pour répondre à ta question comparef, je ne sais pas ce qui est préférable, et je serai ravi de connaitre la réponse à cette question (car j'ai à peu près le même problème)

 

[comparef]

Bah si c'est possible,

-Connexion BDD (mysql_connect(serveur,user,passwd))
-Extractions et requetes diverse
- petit TRAITEMENT
-Extractions et requetes dues au petit traitement
-Deconnexion de la BDD (mysql_close(bdd))
- Traitement

Oui, si je n'ai pas d'autre choix je ferait comme cela, c'est a dire une sorte de pré-traitement et essayer de faire le gros du traitement apres la deconnexion.

il demande pas si c'est possible, mais ce qui est préférable.

Mais pour répondre à ta question comparef, je ne sais pas ce qui est préférable, et je serai ravi de connaitre la réponse à cette question (car j'ai à peu près le même problème)

Oui, en fait je ne sait pas si une connexion consomme beaucoup donc si c'est "rentable" de faire des deconnexions / reconnexions dans une meme page

 

[spidetra]

+ si le traitement est long
+ nbr de connexion à la base est limité
+ souvent des too many connection

=> alors oui, il vaut mieux faire une déconnexion puis une reconnexion.
En terme de perf tu perdras du temps à chaque reconx à ta base.

Dans un premier temps, ta solution la plus simple et la plus rapide en terme de devs est donc bien de gérer tes connx de la sorte.


Dans un deuxième temps, peut-être que tu auras des optimisations à faire dans ton SGBD ou dans ton SQL pour améliorer tout ça.

 

[spidetra]

Oui, en fait je ne sait pas si une connexion consomme beaucoup donc si c'est "rentable" de faire des deconnexions / reconnexions dans une meme page

Ton pb n'est pas un pb de rentabilité. Dans la mesure ou tu as trop souvent des "too many conx", tu dois libérer tes cnx le plus rapidement possible.

 

[comparef]

Merci pour vos reponses.

ok, donc je vais opter pour le deconnexion durant les gros traitement, et des reconnexions si necessaire, en complement d'une mise en cache des pages.

Pour l'optimisation SQL, tu parle de l'optimisation de mes requetes ?

 

[Szarah]

Dans les requêtes, il faut traquer les champs dont on n'a pas besoin ... c'est bête à dire mais ça peut faire économiser un temps fou sans parler de la charge CPU.

 

[spidetra]

Pour l'optimisation SQL, tu parle de l'optimisation de mes requetes ?

Tu dois t'assurer que tes performances sont optimales :

- au niveau SGBD :
=> Ton modèle de donnée doit être nickel
=> Tu dois utiliser des index : PK, FK et colonnes candidates
=> Si ton appli et ta version de mySQL le permet utilise le cache de requêtes.

- au niveau SQL
=> tu dois essayer d'optimiser tes requêtes SQL, si elles peuvent l'être.

Récemment, sur ce forum, un pb de performance dans dotClear venait de l'absence d'index sur une clé étrangère. Ce qui est vraiment une erreur de débutant.

Dans ton cas, ça ne réglera pas directement ton pb de "too many cnx".
Mais si tu peux optimiser n'hésites surtout pas à le faire.

 

[comparef]

Ok, merci, donc je vais commencer par arreter les "SELECT * FROM..." !

Et je vais me renseigner sur les configs dont tu parle.

 

[spidetra]

Evite les SELECT * :
- pour éviter de ramener tout tes champs d'une table et que tu ne doit en utiliser qu'un ou deux.
- pour éviter de ramener des champs de type blob ou text lorsque tu n'en as pas besoin.

sinon tu peux les utiliser.


Tout est une question de mesure !