J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la
connexion à mysql après avoir fait une requête car php s'occupait
automatiquement de ca. Hors j'ai vu sur le site
http://www.toutestfacile.com/phpinit.php?tef_site=php&chap=bd2 qu'il
fallait utiliser la commande mysql_close() (si on a ouvert une connexion
avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
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
Admin web Zicos Prod
Bratignol Frenchy wrote:
Bonjour,
J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la connexion à mysql après avoir fait une requête car php s'occupait automatiquement de ca. Hors j'ai vu sur le site http://www.toutestfacile.com/phpinit.php?tef_site=php&chap½2 qu'il fallait utiliser la commande mysql_close() (si on a ouvert une connexion avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
Merci
perso j'utilise tjrs mysql_close() car j'aime bien refermer tout de suite la bd apres son emploi, certes quand il y a plusieurs appel sur la base je dois redemander l'ouverture de la bd, mais je prefere, meme si cela relenti les pages. a toi de voir?
mysql_close() a tjrs existé. il existe aussi mysql_pconnect -- Ouvre une connexion persistante à un serveur MySQL.
va voir sur mon site j'ai mis la doc en ligne. http://zicos-prod.no-ip.org/documentation/PHP/ref.mysql.html
-- N'oublier pas pour m'écrire de retirer no-spam- à nom adresse émail. Allez voir mon site à l'adresse suivante: http://zicos-prod.no-ip.org/ et bonjour chez vous. °oO lE lInUxIEn OUf Oo° --
Bratignol Frenchy wrote:
Bonjour,
J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la
connexion à mysql après avoir fait une requête car php s'occupait
automatiquement de ca. Hors j'ai vu sur le site
http://www.toutestfacile.com/phpinit.php?tef_site=php&chap½2 qu'il
fallait utiliser la commande mysql_close() (si on a ouvert une connexion
avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
Merci
perso j'utilise tjrs mysql_close() car j'aime bien refermer tout de suite
la bd apres son emploi, certes quand il y a plusieurs appel sur la base je
dois redemander l'ouverture de la bd, mais je prefere, meme si cela relenti
les pages. a toi de voir?
mysql_close() a tjrs existé.
il existe aussi mysql_pconnect -- Ouvre une connexion persistante à un
serveur MySQL.
va voir sur mon site j'ai mis la doc en ligne.
http://zicos-prod.no-ip.org/documentation/PHP/ref.mysql.html
--
N'oublier pas pour m'écrire de retirer no-spam- à nom adresse émail.
Allez voir mon site à l'adresse suivante: http://zicos-prod.no-ip.org/
et bonjour chez vous. °oO lE lInUxIEn OUf Oo°
--
J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la connexion à mysql après avoir fait une requête car php s'occupait automatiquement de ca. Hors j'ai vu sur le site http://www.toutestfacile.com/phpinit.php?tef_site=php&chap½2 qu'il fallait utiliser la commande mysql_close() (si on a ouvert une connexion avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
Merci
perso j'utilise tjrs mysql_close() car j'aime bien refermer tout de suite la bd apres son emploi, certes quand il y a plusieurs appel sur la base je dois redemander l'ouverture de la bd, mais je prefere, meme si cela relenti les pages. a toi de voir?
mysql_close() a tjrs existé. il existe aussi mysql_pconnect -- Ouvre une connexion persistante à un serveur MySQL.
va voir sur mon site j'ai mis la doc en ligne. http://zicos-prod.no-ip.org/documentation/PHP/ref.mysql.html
-- N'oublier pas pour m'écrire de retirer no-spam- à nom adresse émail. Allez voir mon site à l'adresse suivante: http://zicos-prod.no-ip.org/ et bonjour chez vous. °oO lE lInUxIEn OUf Oo° --
Bruno Desthuilliers
Bratignol Frenchy wrote:
Bonjour,
J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la connexion à mysql après avoir fait une requête car php s'occupait automatiquement de ca. Hors j'ai vu sur le site http://www.toutestfacile.com/phpinit.php?tef_site=php&chap½2 qu'il fallait utiliser la commande mysql_close() (si on a ouvert une connexion avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
Using mysql_close() isn't usually necessary, as non-persistent open links are automatically closed at the end of the script's execution. See also freeing resources. ***
Due to the reference-counting system introduced with PHP4's Zend-engine, it is automatically detected when a resource is no longer referred to (just like Java). When this is the case, all resources that were in use for this resource are made free by the garbage collector. For this reason, it is rarely ever necessary to free the memory manually by using some free_result function. ***
Donc, il semblerait que la libération automatique des resources date de PHP4. Ton tutoriel date peut-être un peu ?
Ceci étant, la libération de la resource se fait lorsque le script se termine. Si le script doit travailler un certain temps, il peut être préférable de libérer explicitement les resources dès que possible.
<AMHA> C'est peut-être dû à l'expérience du C ou à une composante maniaque dans ma personnalité, mais j'ai l'habitude de toujours libérer explicitement les resources inutilisées, quelque soit le langage. Ca ne coûte pas beaucoup plus cher (une ou deux lignes de code par resource), et même si ça n'est pas indispensable, ça ne peut pas faire de mal et ça peut faire du bien. </AMHA>
Bruno
Bratignol Frenchy wrote:
Bonjour,
J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la
connexion à mysql après avoir fait une requête car php s'occupait
automatiquement de ca. Hors j'ai vu sur le site
http://www.toutestfacile.com/phpinit.php?tef_site=php&chap½2 qu'il
fallait utiliser la commande mysql_close() (si on a ouvert une connexion
avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
Using mysql_close() isn't usually necessary, as non-persistent open
links are automatically closed at the end of the script's execution. See
also freeing resources.
***
Due to the reference-counting system introduced with PHP4's Zend-engine,
it is automatically detected when a resource is no longer referred to
(just like Java). When this is the case, all resources that were in use
for this resource are made free by the garbage collector. For this
reason, it is rarely ever necessary to free the memory manually by using
some free_result function.
***
Donc, il semblerait que la libération automatique des resources date de
PHP4. Ton tutoriel date peut-être un peu ?
Ceci étant, la libération de la resource se fait lorsque le script se
termine. Si le script doit travailler un certain temps, il peut être
préférable de libérer explicitement les resources dès que possible.
<AMHA>
C'est peut-être dû à l'expérience du C ou à une composante maniaque dans
ma personnalité, mais j'ai l'habitude de toujours libérer
explicitement les resources inutilisées, quelque soit le langage. Ca ne
coûte pas beaucoup plus cher (une ou deux lignes de code par resource),
et même si ça n'est pas indispensable, ça ne peut pas faire de mal et ça
peut faire du bien.
</AMHA>
J'ai vu sur plusieurs bouqins php qu'il n'y avait pas besoin de fermer la connexion à mysql après avoir fait une requête car php s'occupait automatiquement de ca. Hors j'ai vu sur le site http://www.toutestfacile.com/phpinit.php?tef_site=php&chap½2 qu'il fallait utiliser la commande mysql_close() (si on a ouvert une connexion avec mysql_connect).
Il faut utiliser mysql_close() depuis longtemps et est-ce obligatoire?
Using mysql_close() isn't usually necessary, as non-persistent open links are automatically closed at the end of the script's execution. See also freeing resources. ***
Due to the reference-counting system introduced with PHP4's Zend-engine, it is automatically detected when a resource is no longer referred to (just like Java). When this is the case, all resources that were in use for this resource are made free by the garbage collector. For this reason, it is rarely ever necessary to free the memory manually by using some free_result function. ***
Donc, il semblerait que la libération automatique des resources date de PHP4. Ton tutoriel date peut-être un peu ?
Ceci étant, la libération de la resource se fait lorsque le script se termine. Si le script doit travailler un certain temps, il peut être préférable de libérer explicitement les resources dès que possible.
<AMHA> C'est peut-être dû à l'expérience du C ou à une composante maniaque dans ma personnalité, mais j'ai l'habitude de toujours libérer explicitement les resources inutilisées, quelque soit le langage. Ca ne coûte pas beaucoup plus cher (une ou deux lignes de code par resource), et même si ça n'est pas indispensable, ça ne peut pas faire de mal et ça peut faire du bien. </AMHA>
Bruno
Pimousse
AMHA à mon tour ;o)
Pour les technologies web, je dirai plutôt le contraire : on est pas dans une utilisation mono-utilisateur mais multi-utilisateur ! Or ce qui coûte le plus de temps, c'est d'ouvrir une nouvelle connexion, cad démarrer un thread. C'est par ex pour ça que les serveurs te demandent au démarrage combien de threads faut-il démarrer : ces threads sont alors placés ds une file d'attente où ils attendent des tâches à faire. Une fois celle-ci exécutée, ils retournent ds la file d'attente. Il n'y a dc pas nécessité de démarrer et d'arrêter des threads, et ainsi perdre du temps. La seule limite du système est le nombre de threads que tu peux activer simultanément, cad la puissance de ta machine ..
Je pense qu'il faut raisonner de la même manière avec les bdd et ouvrir des connexions du type mysql_pconnect (par contre faut bien penser à les fermer un jour sinon engorgement)
les extraits ci-dessous proviennent de http://fr.php.net/manual/fr/features.persistent-connections.php
Les connexions persistantes aux bases de données SQL sont des connexions qui ne se referment pas à la fin du script. Lorsqu'une connexion persistante est demandée, PHP s'assure qu'il n'y a pas une autre connexion identique (qui serait ouverte précédemment, avec le même nom d'hôte, d'utilisateur et le même mot de passe), et si une telle connexion existe, elle est utilisée. Sinon, elle est créée. Une connexion identique est une connexion qui a ouvert le même hôte, avec le même nom et le même mot de passe (s'ils sont nécessaires). [...] La deuxième méthode, et de loin, la plus prisée, est d'exécuter PHP sous la forme d'un module sur un serveur multi-processus, ce qui revient à dire : Apache. Un tel serveur a typiquement un processus parent qui coordonne un ensemble de processus fils, qui servent les fichiers. Lorsque les requêtes parviennent depuis un client, elles sont transmises à un fils disponible. Cela signifie que si un client fait une deuxième requête, il peut être servi par un processus client différent du premier. Les connexions persistantes vous permettent alors de ne vous connecter à une base SQL que la première fois. Lors des connexions ultérieures, les processus fils pourront réutiliser la connexion ouverte précédemment. [...] La réponse est extrêmement simple : efficacité. Les connexions persistantes sont un bon moyen d'accélérer les accès à une base SQL si le traitement de connexion à la base est long. Ce temps dépend de nombreux facteurs : le type de base de données, cette base est-elle sur le même serveur ou pas, quelle est la charge du serveur de base de données, etc... Si le temps de connexion est long, les connexions persistantes seront bien utiles, car une fois ouverte par un processus fils, la connexion est réutilisable sans avoir à se reconnecter. Si vous avez 20 processus fils, il suffit d'avoir 20 connexions persistantes ouvertes, une par fils.
Notez que les connexions persistantes ont quelques inconvénients si vous hébergez une base de données, dont le nombre maximal de connexion risque d'être atteint par les connexions persistantes. Si votre base de données accepte jusqu'à 16 connexions simultanées et que, 17 processus essaient de se connecter, le dernier restera sur la touche. S'il y a des erreurs dans les scripts qui ne permettent pas de fermer la connexion (par exemple, une boucle infinie), votre serveur sera rapidement engorgé. Vérifiez la documentation de votre base de données pour savoir comment elle traite les connexions inactives ou abandonnées.
Résumons-nous : les connexions persistantes ont été définies pour avoir les mêmes fonctionnalités que les connexions non persistantes. Les deux types de connexions sont parfaitement interchangeables, et n'affecteront pas le comportement de votre script : uniquement son efficacité.
@++ Pimousse
AMHA à mon tour ;o)
Pour les technologies web, je dirai plutôt le contraire : on est pas
dans une utilisation mono-utilisateur mais multi-utilisateur !
Or ce qui coûte le plus de temps, c'est d'ouvrir une nouvelle connexion,
cad démarrer un thread.
C'est par ex pour ça que les serveurs te demandent au démarrage combien
de threads faut-il démarrer : ces threads sont alors placés ds une file
d'attente où ils attendent des tâches à faire. Une fois celle-ci
exécutée, ils retournent ds la file d'attente. Il n'y a dc pas nécessité
de démarrer et d'arrêter des threads, et ainsi perdre du temps. La seule
limite du système est le nombre de threads que tu peux activer
simultanément, cad la puissance de ta machine ..
Je pense qu'il faut raisonner de la même manière avec les bdd et ouvrir
des connexions du type mysql_pconnect (par contre faut bien penser à les
fermer un jour sinon engorgement)
les extraits ci-dessous proviennent de
http://fr.php.net/manual/fr/features.persistent-connections.php
Les connexions persistantes aux bases de données SQL sont des
connexions qui ne se referment pas à la fin du script. Lorsqu'une
connexion persistante est demandée, PHP s'assure qu'il n'y a pas une
autre connexion identique (qui serait ouverte précédemment, avec le même
nom d'hôte, d'utilisateur et le même mot de passe), et si une telle
connexion existe, elle est utilisée. Sinon, elle est créée. Une
connexion identique est une connexion qui a ouvert le même hôte, avec le
même nom et le même mot de passe (s'ils sont nécessaires).
[...]
La deuxième méthode, et de loin, la plus prisée, est d'exécuter PHP
sous la forme d'un module sur un serveur multi-processus, ce qui revient
à dire : Apache. Un tel serveur a typiquement un processus parent qui
coordonne un ensemble de processus fils, qui servent les fichiers.
Lorsque les requêtes parviennent depuis un client, elles sont transmises
à un fils disponible. Cela signifie que si un client fait une deuxième
requête, il peut être servi par un processus client différent du
premier. Les connexions persistantes vous permettent alors de ne vous
connecter à une base SQL que la première fois. Lors des connexions
ultérieures, les processus fils pourront réutiliser la connexion ouverte
précédemment.
[...]
La réponse est extrêmement simple : efficacité. Les connexions
persistantes sont un bon moyen d'accélérer les accès à une base SQL si
le traitement de connexion à la base est long. Ce temps dépend de
nombreux facteurs : le type de base de données, cette base est-elle sur
le même serveur ou pas, quelle est la charge du serveur de base de
données, etc... Si le temps de connexion est long, les connexions
persistantes seront bien utiles, car une fois ouverte par un processus
fils, la connexion est réutilisable sans avoir à se reconnecter. Si vous
avez 20 processus fils, il suffit d'avoir 20 connexions persistantes
ouvertes, une par fils.
Notez que les connexions persistantes ont quelques inconvénients si
vous hébergez une base de données, dont le nombre maximal de connexion
risque d'être atteint par les connexions persistantes. Si votre base de
données accepte jusqu'à 16 connexions simultanées et que, 17 processus
essaient de se connecter, le dernier restera sur la touche. S'il y a des
erreurs dans les scripts qui ne permettent pas de fermer la connexion
(par exemple, une boucle infinie), votre serveur sera rapidement
engorgé. Vérifiez la documentation de votre base de données pour savoir
comment elle traite les connexions inactives ou abandonnées.
Résumons-nous : les connexions persistantes ont été définies pour
avoir les mêmes fonctionnalités que les connexions non persistantes. Les
deux types de connexions sont parfaitement interchangeables, et
n'affecteront pas le comportement de votre script : uniquement son
efficacité.
Pour les technologies web, je dirai plutôt le contraire : on est pas dans une utilisation mono-utilisateur mais multi-utilisateur ! Or ce qui coûte le plus de temps, c'est d'ouvrir une nouvelle connexion, cad démarrer un thread. C'est par ex pour ça que les serveurs te demandent au démarrage combien de threads faut-il démarrer : ces threads sont alors placés ds une file d'attente où ils attendent des tâches à faire. Une fois celle-ci exécutée, ils retournent ds la file d'attente. Il n'y a dc pas nécessité de démarrer et d'arrêter des threads, et ainsi perdre du temps. La seule limite du système est le nombre de threads que tu peux activer simultanément, cad la puissance de ta machine ..
Je pense qu'il faut raisonner de la même manière avec les bdd et ouvrir des connexions du type mysql_pconnect (par contre faut bien penser à les fermer un jour sinon engorgement)
les extraits ci-dessous proviennent de http://fr.php.net/manual/fr/features.persistent-connections.php
Les connexions persistantes aux bases de données SQL sont des connexions qui ne se referment pas à la fin du script. Lorsqu'une connexion persistante est demandée, PHP s'assure qu'il n'y a pas une autre connexion identique (qui serait ouverte précédemment, avec le même nom d'hôte, d'utilisateur et le même mot de passe), et si une telle connexion existe, elle est utilisée. Sinon, elle est créée. Une connexion identique est une connexion qui a ouvert le même hôte, avec le même nom et le même mot de passe (s'ils sont nécessaires). [...] La deuxième méthode, et de loin, la plus prisée, est d'exécuter PHP sous la forme d'un module sur un serveur multi-processus, ce qui revient à dire : Apache. Un tel serveur a typiquement un processus parent qui coordonne un ensemble de processus fils, qui servent les fichiers. Lorsque les requêtes parviennent depuis un client, elles sont transmises à un fils disponible. Cela signifie que si un client fait une deuxième requête, il peut être servi par un processus client différent du premier. Les connexions persistantes vous permettent alors de ne vous connecter à une base SQL que la première fois. Lors des connexions ultérieures, les processus fils pourront réutiliser la connexion ouverte précédemment. [...] La réponse est extrêmement simple : efficacité. Les connexions persistantes sont un bon moyen d'accélérer les accès à une base SQL si le traitement de connexion à la base est long. Ce temps dépend de nombreux facteurs : le type de base de données, cette base est-elle sur le même serveur ou pas, quelle est la charge du serveur de base de données, etc... Si le temps de connexion est long, les connexions persistantes seront bien utiles, car une fois ouverte par un processus fils, la connexion est réutilisable sans avoir à se reconnecter. Si vous avez 20 processus fils, il suffit d'avoir 20 connexions persistantes ouvertes, une par fils.
Notez que les connexions persistantes ont quelques inconvénients si vous hébergez une base de données, dont le nombre maximal de connexion risque d'être atteint par les connexions persistantes. Si votre base de données accepte jusqu'à 16 connexions simultanées et que, 17 processus essaient de se connecter, le dernier restera sur la touche. S'il y a des erreurs dans les scripts qui ne permettent pas de fermer la connexion (par exemple, une boucle infinie), votre serveur sera rapidement engorgé. Vérifiez la documentation de votre base de données pour savoir comment elle traite les connexions inactives ou abandonnées.
Résumons-nous : les connexions persistantes ont été définies pour avoir les mêmes fonctionnalités que les connexions non persistantes. Les deux types de connexions sont parfaitement interchangeables, et n'affecteront pas le comportement de votre script : uniquement son efficacité.
