Bonjour,
Je reprends une application en PHP (on s'en serait douté) qui a la
connexion à la base de données dans un fichier à part et qui est
systématiquement "includé_once" par chaque fichier PHP existant (sauf
quelques exceptions).
Dans le code pris dans sa globalité, aucune fermeture de la connexion à
la base de données.
On teste sur le réseau local, on sent bien les quelques milliers de
requetes générées par les scripts, mais même en y mettant du coeur, on
n'arrive pas à faire raler le serveur de base de données (il devrait
raler à cause du nombre trop important de connexions "ouvertes"), qui a
quand même un paramétrage par défaut (Ubuntu).
Le fait de ne pas fermer la connexion à la base de données semble
contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on
fermer la connexion à la base de donnée apres s'en etre servi?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Le 10/10/2008 00:52, Rakotomandimby (R12y) Mihamina a écrit :
[...]
Le fait de ne pas fermer la connexion à la base de données semble contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on fermer la connexion à la base de donnée apres s'en etre servi?
Configuration: PHP5, Mysql 5, Ubuntu server 8.04.
Dans <http://fr2.php.net/manual/fr/language.types.resource.php>, à l'erreur de traduction près, on lit :
<cit.> Libération des ressources
[Grâce au] système de comptage des références, introduit dans le moteur Zend PHP 4, une ressource qui n'a plus aucune référence est détectée automatiquement, et est libérée par le collecteur. Pour cette raison, il est rarement nécessaire de libérer la mémoire manuellement. </cit.>
Le 10/10/2008 00:52, Rakotomandimby (R12y) Mihamina a écrit :
[...]
Le fait de ne pas fermer la connexion à la base de données semble
contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on
fermer la connexion à la base de donnée apres s'en etre servi?
Configuration: PHP5, Mysql 5, Ubuntu server 8.04.
Dans <http://fr2.php.net/manual/fr/language.types.resource.php>, à
l'erreur de traduction près, on lit :
<cit.>
Libération des ressources
[Grâce au] système de comptage des références, introduit dans le moteur
Zend PHP 4, une ressource qui n'a plus aucune référence est détectée
automatiquement, et est libérée par le collecteur. Pour cette raison, il
est rarement nécessaire de libérer la mémoire manuellement.
</cit.>
Le 10/10/2008 00:52, Rakotomandimby (R12y) Mihamina a écrit :
[...]
Le fait de ne pas fermer la connexion à la base de données semble contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on fermer la connexion à la base de donnée apres s'en etre servi?
Configuration: PHP5, Mysql 5, Ubuntu server 8.04.
Dans <http://fr2.php.net/manual/fr/language.types.resource.php>, à l'erreur de traduction près, on lit :
<cit.> Libération des ressources
[Grâce au] système de comptage des références, introduit dans le moteur Zend PHP 4, une ressource qui n'a plus aucune référence est détectée automatiquement, et est libérée par le collecteur. Pour cette raison, il est rarement nécessaire de libérer la mémoire manuellement. </cit.>
Sylvain SF
Rakotomandimby (R12y) Mihamina a écrit :
Le fait de ne pas fermer la connexion à la base de données semble contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on fermer la connexion à la base de donnée apres s'en etre servi?
Configuration: PHP5, Mysql 5, Ubuntu server 8.04.
selon la doc (de mysql_connect):
The link to the server will be closed as soon as the execution of the script ends, unless it's closed earlier by explicitly calling mysql_close().
Sylvain.
Rakotomandimby (R12y) Mihamina a écrit :
Le fait de ne pas fermer la connexion à la base de données semble
contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on
fermer la connexion à la base de donnée apres s'en etre servi?
Configuration: PHP5, Mysql 5, Ubuntu server 8.04.
selon la doc (de mysql_connect):
The link to the server will be closed as soon as the execution of
the script ends, unless it's closed earlier by explicitly calling
mysql_close().
Le fait de ne pas fermer la connexion à la base de données semble contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on fermer la connexion à la base de donnée apres s'en etre servi?
Configuration: PHP5, Mysql 5, Ubuntu server 8.04.
selon la doc (de mysql_connect):
The link to the server will be closed as soon as the execution of the script ends, unless it's closed earlier by explicitly calling mysql_close().
Sylvain.
Pascal PONCET
Rakotomandimby (R12y) Mihamina a écrit :
Le fait de ne pas fermer la connexion à la base de données semble contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on fermer la connexion à la base de donnée apres s'en etre servi?
Bonjour,
Effectivement, la fermeture est automatique depuis PHP4. La libération de ressource se fait à la fin du script.
Si les fonctions de fermeture sont encore disponibles dans les API des différents SGBD supportés par PHP, c'est uniquement pour permettre la libération de ressource dans un même script global en cours (par "global", j'entends comme tenant compte de tous les include demandés, donc le script vu du côté du moteur Zend).
C'est surtout intéressant, je crois, lorsqu'on a besoin de se connecter à plusieurs serveurs SGBD de façon consécutive dans le script global. On peut ainsi en libérer un dès qu'on a fini les requêtes lui étant adressées.
Ça n'a, par contre, aucun rapport avec le nombre de connexions simultanées sur un serveur ou, corolaire, le nombre d'utilisateurs connectés.
Cordialement, Pascal
Rakotomandimby (R12y) Mihamina a écrit :
Le fait de ne pas fermer la connexion à la base de données semble
contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on
fermer la connexion à la base de donnée apres s'en etre servi?
Bonjour,
Effectivement, la fermeture est automatique depuis PHP4.
La libération de ressource se fait à la fin du script.
Si les fonctions de fermeture sont encore disponibles dans les API des
différents SGBD supportés par PHP, c'est uniquement pour permettre la
libération de ressource dans un même script global en cours (par
"global", j'entends comme tenant compte de tous les include demandés,
donc le script vu du côté du moteur Zend).
C'est surtout intéressant, je crois, lorsqu'on a besoin de se connecter
à plusieurs serveurs SGBD de façon consécutive dans le script global.
On peut ainsi en libérer un dès qu'on a fini les requêtes lui étant
adressées.
Ça n'a, par contre, aucun rapport avec le nombre de connexions
simultanées sur un serveur ou, corolaire, le nombre d'utilisateurs
connectés.
Le fait de ne pas fermer la connexion à la base de données semble contenu par un espece de ramasse miette. Est-ce le cas? Devrait-on fermer la connexion à la base de donnée apres s'en etre servi?
Bonjour,
Effectivement, la fermeture est automatique depuis PHP4. La libération de ressource se fait à la fin du script.
Si les fonctions de fermeture sont encore disponibles dans les API des différents SGBD supportés par PHP, c'est uniquement pour permettre la libération de ressource dans un même script global en cours (par "global", j'entends comme tenant compte de tous les include demandés, donc le script vu du côté du moteur Zend).
C'est surtout intéressant, je crois, lorsqu'on a besoin de se connecter à plusieurs serveurs SGBD de façon consécutive dans le script global. On peut ainsi en libérer un dès qu'on a fini les requêtes lui étant adressées.
Ça n'a, par contre, aucun rapport avec le nombre de connexions simultanées sur un serveur ou, corolaire, le nombre d'utilisateurs connectés.
Cordialement, Pascal
Antoine ROUCHET
"Rakotomandimby (R12y) Mihamina" wrote in message news:gclv38$2bsv$
On teste sur le réseau local, on sent bien les quelques milliers de requetes générées par les scripts, mais même en y mettant du coeur, on n'arrive pas à faire raler le serveur de base de données (il devrait raler à cause du nombre trop important de connexions "ouvertes"), qui a quand même un paramétrage par défaut (Ubuntu).
Bonjour,
Pourquoi devrait-il y avoir un nombre important de connexions ouvertes?
Si le script créant la connexion est reférencé via la directive include_once(), alors il n'est inclu qu'une seule fois, et donc exécuté qu'une seule fois (par session évidemment).
De plus, la fonctione mysql_connect() en elle même ne permet pas (sauf demande explicite) d'ouvrir 2 connexions distincts vers un même serveur MySQL (avec le même login et le même password). En résumé, si je fais:
alors $b est une copie de $a et une seule connexion vers le serveur MySQL est ouverte.
Antoine.
"Rakotomandimby (R12y) Mihamina" <mihamina@infogerance.us> wrote in message
news:gclv38$2bsv$1@cabale.usenet-fr.net...
On teste sur le réseau local, on sent bien les quelques milliers de
requetes générées par les scripts, mais même en y mettant du coeur, on
n'arrive pas à faire raler le serveur de base de données (il devrait raler
à cause du nombre trop important de connexions "ouvertes"), qui a quand
même un paramétrage par défaut (Ubuntu).
Bonjour,
Pourquoi devrait-il y avoir un nombre important de connexions ouvertes?
Si le script créant la connexion est reférencé via la directive
include_once(), alors il n'est inclu qu'une seule fois, et donc exécuté
qu'une seule fois (par session évidemment).
De plus, la fonctione mysql_connect() en elle même ne permet pas (sauf
demande explicite) d'ouvrir 2 connexions distincts vers un même serveur
MySQL (avec le même login et le même password). En résumé, si je fais:
"Rakotomandimby (R12y) Mihamina" wrote in message news:gclv38$2bsv$
On teste sur le réseau local, on sent bien les quelques milliers de requetes générées par les scripts, mais même en y mettant du coeur, on n'arrive pas à faire raler le serveur de base de données (il devrait raler à cause du nombre trop important de connexions "ouvertes"), qui a quand même un paramétrage par défaut (Ubuntu).
Bonjour,
Pourquoi devrait-il y avoir un nombre important de connexions ouvertes?
Si le script créant la connexion est reférencé via la directive include_once(), alors il n'est inclu qu'une seule fois, et donc exécuté qu'une seule fois (par session évidemment).
De plus, la fonctione mysql_connect() en elle même ne permet pas (sauf demande explicite) d'ouvrir 2 connexions distincts vers un même serveur MySQL (avec le même login et le même password). En résumé, si je fais:
