Discussion :

[dabac]

Bonjour,

J'ai une application composée de plusieurs pages php dont chacune consulte et/ou met à jour des tables de ma base de données; Plusieurs gestionnaires utilisent simultanément cette application et le moteur de ma base de données est MyIsam;
Chacune de mes pages commence par la connection à ma base de données (instruction mysql_select_db($database_connectYieldProduc, $connectYieldProduc) );

L'instruction mysql_close est elle nécessaire et quand doit elle être utilisée ?

Merci de consacrer un peu de votre temps à mon problème.

[vorace]

Je ne me souviens plus ou je l'avais lu mais mysql_close permet d'optimiser tes pages...à mettre partout ou tu as de la requete en fin de script...

[Séb.]

Utilise mysql_close( ) dès que tu n'as plus besoin d'accéder à la BdD.
Cela permet de libérer une connexion au serveur MySQL.

La doc http://fr2.php.net/mysql-close :

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.

[rawsrc]

Je ne me souviens plus ou je l'avais lu mais mysql_close permet d'optimiser tes pages...à mettre partout ou tu as de la requete en fin de script...

Ah, j'ai lu le contraire
Normalement pour les connexions non persistantes, il est préférable de laisser PHP gérer automatiquement la clôture (bien plus rapide) par contre dans certains cas où tu ferais appels à plusieurs connexions sans les identifier explicitement, il est nécessaire de les fermer manuellement.

[ABCIWEB]

Je rejoins rawsrc et la citation de Seb.
Et dans certains cas où différents blocs de code doivent utiliser une connexion à l'intérieur d'un même script, l'utilisation de mysq_close peut poser des problèmes (connexion perdue). A ta place je laisserais plutôt faire php.

[vorace]

Ah, j'ai lu le contraire
Normalement pour les connexions non persistantes, il est préférable de laisser PHP gérer automatiquement la clôture (bien plus rapide) par contre dans certains cas où tu ferais appels à plusieurs connexions sans les identifier explicitement, il est nécessaire de les fermer manuellement.

et pourtant (http://www.vulgarisation-informatiqu...iser-mysql.php), mais juste pour correction la fermeture doit se faire après la dernière requête et non à la fin du script puisque effectivement la fermeture se fait automatiquement...

[RunCodePhp]

et pourtant (http://www.vulgarisation-informatiqu...iser-mysql.php), mais juste pour correction la fermeture doit se faire après la dernière requête et non à la fin du script puisque effectivement la fermeture se fait automatiquement...

Le problème c'est qu'il ne donne pas vraiment d'explications, aucune même.

De mon coté, certes c'est juste une idée personnelle que je me suis fait, cette idée serait inverse.
Je m'explique.
Il est dit dans la doc (pour les fonction mysql_* et pour une connexion non persistante) que par défaut MySQL reprend automatiquement la dernière connexion ouverte.
Dans le code qu'il y a dans ce tuto rien n'est précisé concernant la connexion, c'est à dire qu'aucun lien de la ressource ($link en général) n'est indiquée explicitement au niveau des fonctions :
mysql_query('...', aucun lien indiqué ici)
mysql_close(aucun lien indiqué ici)
mysql_fetch_array($requete, aucun lien indiqué ici)
-> Ce sera alors la connexion par défaut qui sera utilisée (la dernière ouverte).

Donc si on ferme la connexion (mysql_close) et qu'après on utilise mysql_fetch_array(), il faut bien quelque part une référence à la connexion.
Et bien je me dis que (donc théoriquement) MySQL va ré-ouvrir la dernière connexion ouverte, théoriquement la même que celle qui a servie à faire la requête juste avant.

Et bien ceci ne reviendrait-il pas au même de ne pas fermer la connexion ?
Le fait de fermer puis le fait de ré-ouvrir tout de suite après, ne serait-il pas moins optimisé/performant que de ne pas fermer ?


Bref ... je ne suis pas convaincu que fermer la connexion soit plus optimiser que de laisser MySQL générer tout ça.
De plus il me semble bien avoir lu dans la doc (je ne sais plus où) que MySQL gérait particulière bien cette phase là.
Puis il me semble bien aussi avoir lu qu'il est préférable de fermer une connexion que si on fait des connexions persistantes (cas très rare).


Maintenant, on sait (pour la plupart) que les fonctions mysql (mysql_*) sont obsolètes et vouées à disparaitre du core de Php.
Il n'a donc quelque part pas lieu de se prendre la tête sur ce point là.

Par conséquent, comme il est fortement conseillé d'utiliser PDO ou MySQLi, quand est il pour ces 2 là ?
Là aussi vaut-il mieux faire des fermeture/ré-ouverture de connexion à chaque requête ?
En regardant un peu comment cela se fait (genre CMS, FrameWork), en général (voir toujours) c'est une connexion qui est 1 fois ouverte et c'est la même qui est utilisée tout le long du script.
En somme, on laisse Php détruire l'instance (de la connexion), et théoriquement ça se fera lorsqu'elle ne sera plus utilisée.


Tout cela est un avis personnel bien sûr, faut voir si l'idée correspond à la réalité ou pas.

[KstorTroy]

T'as mis le doigt sur une de plus grand mystère du php ! ^^
Pourquoi mysql_close existe-t-il ???

La connexion se ferme automatiquement à la fin du script.
Si les pages ne sont pas gourmandes en ressources et qu'il n'y'a qu'une seule connexion nécessaire pour le script, inutile d'utiliser mysql_close.

En revanche,
Si tu as une simple requête dans ton script et que s'en suit un script très gourmand, pour éviter qu'une connexion persiste longtemps alors qu'elle est inutile, il vaut mieux mettre fin à la connexion. Pour libérer le collecteur le plus rapidement possible.
Et inversement si tu as un script lourd en premier, il vaut mieux faire la connexion avec mysql au dernier moment.
Ceci afin que la connexion dure le moins longtemps possible.

Le mieux est de toujours l'utiliser par défaut.
C'est pas pour c'que bouffe en octet et en ram la ligne mysql_close;

Il faut se connecter au dernier moment et se déconnecter dès qu'on en a plus besoin. Histoire de n'avoir que de bonnes habitudes...

Là aussi vaut-il mieux faire des fermeture/ré-ouverture de connexion à chaque requête ?

--> le mieux c'est de regrouper toutes tes requêtes en tête de script. non ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<?php
//connection
//toutes les req necess au script
//deconnection
// -> (temps de connection à la bdd optimal)
//traitement
?>
<html>
<body>
<?php echo $donneetraitee; ?>
...

J'utilise tout l'temps ce schéma là. Mais c'est vrai qu'j'suis pas non plus un utiliseur régulier de cette fonction presque inutile puisque nos scripts ne doivent de toutes façons pas être lourds pour le bonheur de nos invités ! ^^
C'est important de l'utiliser quand on a des tâches planifiées qui pètent des records en temps d'éxécution comme la génération de graphiques, de pdf's, ou d'envoi de mails et qu'on est à la limite de faire fumer son serveur mysql.
Mais pour la plupart des sites meme dans ces cas particuliers, c'est inutile.
Pour y trouver une utilité nécessaire, il faut s’intéresser aux connexion persistantes.

2 solutions s'offrent à toi:
A. Tu l'mets parc'que tu t'en fous de faire 2 mysql_close (un manu et un auto) et tu préfère prendre de bonnes habitudes ou parc'que tout simplement t'es cartésien ou qu'tu risques d'avoir des scripts lourds.
B. Tes scripts sont pas gourmands, t'es pas cartésiens et tu es sure de pas oublier de le faire si tes scripts s'alourdissent et tu l'mets pas.

Dans l'cas A tu favorises les performances mysql au détriment des performances php. (dans c'cas-ci, c'est minime)
Dans l'cas B tu favorises les performances php au détriment des performances mysql.

C'est à toi de voir !

[RunCodePhp]

En revanche,
Si tu as une simple requête dans ton script et que s'en suit un script très gourmand, pour éviter qu'une connexion persiste longtemps alors qu'elle est inutile, il vaut mieux mettre fin à la connexion. Pour libérer le collecteur le plus rapidement possible.
Et inversement si tu as un script lourd en premier, il vaut mieux faire la connexion avec mysql au dernier moment.
Ceci afin que la connexion dure le moins longtemps possible.

Le mieux est de toujours l'utiliser par défaut.
C'est pas pour c'que bouffe en octet et en ram la ligne mysql_close;

Humm, je ne suis pas encore tout à fais convaincu.
N'y aurait-il pas confusion entre ces 2 fonctions mysql_close() et mysql_free_result() ?


Ce que dit la doc concernant : mysql_close()

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.

Et pour la libération des ressources :

Sachant qu'une ressource qui n'a plus aucune référence est détectée automatiquement et est libérée par le collecteur, il est rarement nécessaire de libérer la mémoire manuellement.

Et maintenant ce qui est dit dans la doc pour mysql_free_result() :

mysql_free_result() libère toute la mémoire et les ressources utilisées par la ressource de résultat result.

mysql_free_result() n'est à appeler que si vous avez peur d'utiliser trop de mémoire durant l'exécution de votre script. Toute la mémoire associée à l'identifiant de résultat sera automatiquement libérée.

Si je tente de résumer ce qui est dit :
Pour mysql_close() si on utilise une connexion non persistante et si on utilise la même connexion pour toutes les requêtes (cas largement le plus fréquent) il n'est pas utile de fermer la connexion, le collecteur détecte automatiquement si une ressource n'a plus de référence.

Par contre, si on a des traitements très lourds entre 2 requêtes ou à la suite d'une requête, libérer la mémoire avec mysql_free_result() est conseillé.


Qu'en pensez-vous :
Amalgame ou pas amalgame entre ces 2 fonctions mysql_close() mysql_free_result() ?
Puis conserver une référence à une ressource de connexion MySQL est-elle si lourde que ça en mémoire ? (j'en ai pas l'impression)

C'est pas pour c'que bouffe en octet et en ram la ligne mysql_close;

Faut-il se focaliser uniquement sur la mémoire occupée par une ressource de connexion ?

Là encore c'est une idée que je me fais (idée reçue ou pas, à voir), mais qu'en est il de la communication entre Php et MySQL ?
C'est à dire où et comment sont installés Php et MySQL ?
Même serveur/réseau, même espace disque ?
Je me dis qu'il doit bien avoir des infos qui circulent entre ces 2 là, que cela occupera de la mémoire, mais aussi du temps, non ?
La doc de Php ne fait pas vraiment état de cet aspect là.

Admettons comme c'est fait sur le tuto "vulgarisation" qu'on ferme systématiquement la connexion (mysql_close), je me dis que l'info doit forcément circuler quelque part entre Php et MySQL, il doit avoir un temps de latence qui risque d'être plus ou moins long selon comment tout ça est installé.
Donc je me dis que faire des fermetures/ré-ouvertures de connexions risque d'être très couteux en temps, peut être désastreux même alors qu'en mémoire cela représenterait très peux.

Donc fermer une connexion systématiquement à chaque requête est-il si judicieux que ça ?
Pas si sûr ...


Cependant, rassembler toutes ses requêtes, toutes les faire d'une traite pour fermer la connexion qu'1 seule fois à la fin, même en le faisant soit même, pourquoi pas.

[vorace]

@RunCodePhp : l'idée est que pour tout serveur mysql et tout autre serveur de bdd tu a un nombre de connexion possible limité, admettons dans notre cas qu'il soit de 10 : à un temps T, 10 utilisateurs consultent notre site, chaque page exécutant des requêtes qui une fois qu'elle sont toutes exécutées renvoient un résultat que le reste de la page traite...traitement qui mets supposons 10 seconde, durant ces 10 secondes les connexions crées ou réutilisées ne sont plus disponible pour le 11 ième et plus utilisateur qui vient derrière. Du coup les pages sont plus lentes à afficher pour ces utilisateurs...après ce n'est que ma conception des choses et reste à vérifier mais il est vrai que très souvent je me suis posé les mêmes question et je rejoint KstorTroy sur le fait qui il y ait des bonnes pratiques même si la plus part du temps on crée des sites qui ne sont pas pris d'assaut par les visiteurs...ce n'est pas plus une optimisation de mémoire que de temps de réponse...

[RunCodePhp]

l'idée est que pour tout serveur mysql et tout autre serveur de bdd tu a un nombre de connexion possible limité, admettons dans notre cas qu'il soit de 10 : à un temps T, 10 utilisateurs consultent notre site, chaque page exécutant des requêtes qui une fois qu'elle sont toutes exécutées renvoient un résultat que le reste de la page traite...traitement qui mets supposons 10 seconde, durant ces 10 secondes les connexions crées ou réutilisées ne sont plus disponible pour le 11 ième et plus utilisateur qui vient derrière

Pour cela il faudrait voir comment MySQL gère les utilisateurs.

Personnellement je me réfère à la doc.
La doc dit que si on ferme une connexion et si après (même longtemps après) on effectue une nouvelle requête, MySQL tente de reprendre la même connexion, la même ressource.
C'est ce qui est fait en général, on ferme une connexion mais on ne ré-ouvre pas une nouvelle connexion (pas de mysql_connect).

Normalement l'utilisateur c'est Php (rien avoir avec HTTP), par conséquent la ressource serait la même quelque soit les traitements effectués et la longueur du script et même de la mémoire que cela prendrait.
Donc le problème du nombre de connexion simultanée persisterait quand même.


Pour ma part j'ai plutôt l'impression que fermer la connexion systématiquement à chaque requête serait un faut problème.

Le fond du problème serait bien plus une optimisation de son propre code que cette fermeture de connexion.


Ce que KstorTroy à suggérer, c'est à dire de rassembler se requêtes et récupérations des données pour différer plus tard, à la fin, les traitements (plus ou moins lourds), là on gagnerait en optimisation.
Je partage bien plus cette idée là, et c'est bien plus une optimisation du code.
Mais faire cela pour fermer soit même qu'1 seule fois la connexion à la fin reviendrait au même à ne pas le faire vu que Php est déjà optimisé pour ça.

Grosso modo, plus vite on exploitera MySQL (donc en rassemblant cela) plus vite cela libèrera la connexion, du coup cela permettra à d'autre de l'utiliser (plutôt que de la mobiliser longtemps)

C'est pour cela que la doc dit qu'il est rarement nécessaire de fermer la connexion.

[vorace]

@RunCodePhp on est d'accord, fermer la connexion en fin de script ne sert à rien, le faire après la dernière requête exécuté (quelque soit "l'algorithme" et ses embranchement) n'a d'utilité que si après cette fermeture le traitement qui suit est lourd et long...parce que rassembler toutes les requêtes aux même endroit n'est pas toujours possible.

[RunCodePhp]

@vorace
Dans les grandes ligne on aurait la même vision

Mais prenons ces 2 déroulements différents avec ton exemple, c'est à dire une 10ème connexion, la dernière autorisée, donc une 11ème provoquera une erreur.

On va admettre que la nouvelle connexion sera demandée pendant le traitement long.

Cas 1 :
- Ouverture de la connexion (1 ressource -> la 10ème)
- 1ère requête SQL
- 2ème requête SQL
- traitement long (genre 10s)
- Fin de tout le code pour la page demandée
(je précise qu'aucun code ne ferme la connexion)

Cas 2 :
- Ouverture de la connexion (1 ressource -> la 10ème)
- 1ère requête SQL
- fermeture de la connexion -> mysql_close()
- traitement long (genre 10s)
- 2ème requête SQL
- fermeture de la connexion -> mysql_close()
- Fin de tout le code pour la page demandée


Lequel des 2 causera plus de problème, le 1er ou le 2ème cas ?

De mon coté j'ai tendance à penser que le 1er cas ne causera aucun problème.
Théoriquement, et même en ne fermant pas explicitement la connexion (pas de mysql_close) la ressource devrait être libérée avant d'effectuer la partie de traitement long.

Pour le 2ème cas :
C'est là où j'admets ne pas savoir comment cela va être géré.
Je vois 2 façons différentes comment ça pourrait se faire.
Les 2 présenteraient tout de même un problème.

1/ Soit Php (ou/et MySQL peu importe) tient compte stricto texto le code effectué.
La 1ère requête serait faite sans encombre, y compris l'appel à mysql_close().
Le traitement long s'exécute, et c'est là qu'une nouvelle connexion est demandée.
Cette nouvelle connexion se ferait sans erreur car la 10ème étant libérée le nombre de connexion resterait toujours à 10.
Par contre, l'exécution de la 2ème requête provoquerait une erreur, ce serait une 11ème connexion (non autorisée).

2/ Soit Php (ou/et MySQL peu importe) analyse la globalité du code qui sera exécuté, voit qu'une 2ème requête devra être faite en dernier et fera en sorte de conserver la même connexion même pendant le long traitement malgré l'appel à mysql_close() effectué à la 1ère requête.
Lors du long traitement, cette nouvelle connexion demandée provoquerait alors une erreur car ce serait une 11ème, la 10ème étant conservée.


Voilà un peu comment je visualise les choses.
Grosso modo, malgré fermer explicitement les connexions à chaque fois cela ne règlerait rien à un éventuel problème de limitation de connexions.
L'optimisation serait plus efficace en faisant cela autrement.


De votre coté, comment pensez-vous que cela sera géré selon cet exemple ?
Comme l'un des cas évoqué ci-dessus ?
Ou tout autrement ?
En somme, où est le gain à faire un mysql_close() ? (je ne vois toujours pas)

[KstorTroy]

@Run:

Mysql_free_result
Mysql_free_result est a éviter avec les connexion non-persistantes. cfr la doc
En effet Mysql_free_result trouve son utilité dans le fait qu'avec les connexion persistantes, il faut vider le collecteur manuellement de chaque ressource parc'que le il ne le fait pas tout seul.

Par contre, les fonctions mysql_**** demandent une connexion à la base de donnée en effet... :s
J'avais pas pensé à ça. Si vous avez des infos supplémentaires...

En gros, il faudrait fermer la connexion avant un gros script et la ré-ouvrir après si nécessaire. Dans d'autres cas, c'est pas utile de le faire surtout si mysql est peu sollicité.

[RunCodePhp]

Mysql_free_result est a éviter avec les connexion non-persistantes. cfr la doc
En effet Mysql_free_result trouve son utilité dans le fait qu'avec les connexion persistantes, il faut vider le collecteur manuellement de chaque ressource parc'que le il ne le fait pas tout seul.

Tu voulais plutôt dire : une connexion persistante, non ?
Mais malgré tout il y a confusion à mon sens entre la ressource de la connexion (ce que retourne mysql_connect) et la ressource du résultat (ce que retourne mysql_query).

Ce qui est dit dans la doc :

mysql_free_result() libère toute la mémoire et les ressources utilisées par la ressource de résultat result.

mysql_free_result() libère la mémoire de ce que retourne mysql_query, pas mysql_connect.

Donc par rapport à ce qui est dit concernant le cas particulier d'une connexion persistante, c'est une exception, Php ne libère pas un ressource de type connexion.
Mais pour une ressource de type résultat (qui n'est pas la même chose), Php devrait la libérer automatiquement.
Donc au final, qu'on fasse une connexion persistante ou non persistante Php libèrera automatique une ressource de type résultat, donc il serait inutile de le faire.


Je reviens un peu concernant mes exemples plus haut, car j'avais un moment un doute, et il se confirme en faisant rapidement un essai.
Il n'est pas possible d'appeler mysql_close() pour tout de suite après appeler mysql_query(), ça provoquera une erreur.
Normal, vu qu'on a fermé la connexion.

Ca veut dire que si on ferme la connexion il faut la ré-ouvrir explicitement après si on prévoit de faire une requête (mysql_connect-mysql_select_db).

Et bien c'est là où j'estime qu'il ne serait pas judicieux de faire des successions d'ouvertures/fermetures de connexion, c'est théoriquement couteux en temps.
On peu certes en avoir besoin, mais ça fait parti des cas particuliers, ce n'est pas une généralité.
(Un cas particulier à été évoqué au tout début, c'est lorsqu'on a besoin de se connecter sur plusieurs serveurs MySQL, ici fermer la connexion pour ouvrir une nouvelle serait mieux au lieu d'en cumuler plusieurs inutilement).

Dans la généralité on utilisera une seule connexion pour toutes ces requêtes.
Donc cela sous entend qu'on pourrait éventuellement fermer qu'1 seule fois la connexion, et à la fin bien sûr, lors de la dernière requête.

Et c'est là où j'estime que c'est inutile du fait que Php est capable de détecter une ressource non exploitée (plus aucune référence) et la libère automatiquement.
Donc faire un mysql_close() dans ce cas est inutile.

Mais encore, si on fait un petit site, code simple, comme un code procédural, peut être sera t-il très simple de savoir quand la dernière requête sera faite pour rajouter soit même un mysql_close() au bon moment.

Mais pour un site plus évolué/avancé, genre Objet, voir aussi du type MVC, il est pas si évident d'être certain quand la dernière requête sera faite pour fermer la connexion au moment le plus optimisé.
Il y a de forte chance que Php saura le faire mieux que nous.
Pure hypothèse cependant.


Je ne sais pas si vous voyez mon raisonnement.
Est il juste ???

[vorace]

Citation:
Envoyé par KstorTroy
Mysql_free_result est a éviter avec les connexion non-persistantes. cfr la doc
En effet Mysql_free_result trouve son utilité dans le fait qu'avec les connexion persistantes, il faut vider le collecteur manuellement de chaque ressource parc'que le il ne le fait pas tout seul.
Tu voulais plutôt dire : une connexion persistante, non ?
Mais malgré tout il y a confusion à mon sens entre la ressource de la connexion (ce que retourne mysql_connect) et la ressource du résultat (ce que retourne mysql_query).

Ce qui est dit dans la doc :
Citation:
mysql_free_result() libère toute la mémoire et les ressources utilisées par la ressource de résultat result.
mysql_free_result() libère la mémoire de ce que retourne mysql_query, pas mysql_connect.

mysql_free_result libère les ressources de type mysql_result et mysql_close libère les ressources de type mysql_link créée par mysql_connect
http://www.php.net/manual/fr/resource.php

[KstorTroy]

mysql_free_result libère les ressources de type mysql_result et mysql_close libère les ressources de type mysql_link créée par mysql_connect
http://www.php.net/manual/fr/resource.php

Dans le cas d'une connexion non-persistante, les ressource de type "result" sont directments éliminées du collecteur si elles n'ont plus de référence.
Par contre, il faut les éliminer avec mysql_free_result en connection persistante.
Sachant qu'une ressource qui n'a plus aucune référence est détectée automatiquement et est libérée par le collecteur, il est rarement nécessaire de libérer la mémoire manuellement.
Note: Les connexions persistantes aux bases de données sont des exceptions à cette règle. Elles ne sont pas détruites par le collecteur. Voir la section sur les connexions persistantes pour plus d'informations.

http://www.php.net/manual/fr/language.types.resource.php#language.types.resource.self-destruct

Avec une connexion non-persistante, les ressources de type "result" sont vidées automatiquement, donc pas besoin de les gérer avec mysql_free_result, autant laisser faire mysql. Mysql_free_result est donc carrément à proscrire (pollution) si on est pas en connexion persistante. C'était bien ça ! ^^
Par contre selon moi, la ressource de type 'link' due à la connexion persiste tant qu'on ne la ferme pas.
Ou cette ressource là est-elle gérée par mysql aussi ?
S'en débarasse-t-il dès qu'il n'en a plus besoin aussi plutôt qu'en fin d'exécution ? ( The Run Theory)
Si c'est le cas, j'ai dis que de grosses bêtises et j'espère que vous comprendrez, je veux voir des preuves...

Parc'que tout c'que j'ai lu pour l'instant à propose de ça, c'est ç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.

http://php.net/manual/fr/function.mysql-close.php

En attendant, si TOUT le script s'exécute en plus de 0.XXXXs (dépend de vos besoins), je continuerai de suggérer de fermer manuellement la connexion dès qu'on en a plus l'utilité. Et meme plus, de regrouper un maximum toutes les requêtes et fonctions nécessitants une connexion à mysql afin que d'la place soit faite dans collecteur le plus rapidement possible.

I faut donc éviter:
connexion
req
deconnexion
script lourd
while ($$$ < mysql_($$$)){...
Qui fonctionne en local chez moi mais pas en ligne, il réclame que je ne ferme pas la connexion.
Il est possible que mysql se reconnecte

connexion
req
script lourd
while ($$$ < mysql_($$$)){...
La ressource de type link va rester dans le collecteur le temps d'exécution.

connexion
req
script lourd
while ($$$ < mysql_($$$)){...
deconnexion
Ca n'en parlons meme pas.

Et plutôt faire
connexion
req
$$$ = mysql_($$$)
deconnexion
script lourd
while ($$$ < $$$ ){...
C'est pas valable juste pour les requêtes mais pour toutes les fonctions nécessitant une connexion à mysql.

[dabac]

Je vous remercie tous de vous être autant impliqué dans mon problème et de m'avoir ainsi éclairé sur la solution à prendre dans mon contexte
Encore une fois très sincèrement merci