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
john gallet
Bonjour,
mysql_close ne ferme pas la connection persistante...
Et bien j'ai appris quelque chose aujourd'hui, il me semblait que justement le piège était qu'elle le faisait donc qu'il fallait surtout "oublier" de l'appeler. Changement récent ? Bref.
ben alors, quand est ce que cette connection se ferme ?? (elle se ferme bien un jour non ??)
Quatre acteurs peuvent fermer la socket si on est en base distante, trois sinon.
Le moteur Zend, détectant que cette socket n'a pas été utilisée depuis longtemps, doit probablement pouvoir la zapper. S'il ne le fait pas, il doit en être techniquement capable en tous cas. Au dessus, le process apache ou le serveur multithread peut décider de mettre fin au process/thread. La base de données peut elle aussi décider que l'inactivité a suffisement duré et mettre fin à la connexion.
Si on est en base distante, les équipements réseau, qui disposent souvent de deux temps de session (le temps total et le temps d'inactivité) peuvent couper la socket.
Et enfin, n'oublions pas le cas classique de l'être humain moyen qui débranche un câble sans s'en apercevoir en faisant une intervention en salle machine ;-)
a++ JG
Bonjour,
mysql_close ne ferme pas la connection persistante...
Et bien j'ai appris quelque chose aujourd'hui, il me semblait que
justement le piège était qu'elle le faisait donc qu'il fallait surtout
"oublier" de l'appeler. Changement récent ? Bref.
ben alors, quand est ce que cette connection se ferme ?? (elle se ferme
bien un jour non ??)
Quatre acteurs peuvent fermer la socket si on est en base distante,
trois sinon.
Le moteur Zend, détectant que cette socket n'a pas été utilisée depuis
longtemps, doit probablement pouvoir la zapper. S'il ne le fait
pas, il doit en être techniquement capable en tous cas. Au dessus, le
process apache ou le serveur multithread peut décider de mettre fin au
process/thread. La base de données peut elle aussi décider que
l'inactivité a suffisement duré et mettre fin à la connexion.
Si on est en base distante, les équipements réseau, qui disposent
souvent de deux temps de session (le temps total et le temps
d'inactivité) peuvent couper la socket.
Et enfin, n'oublions pas le cas classique de l'être humain moyen qui
débranche un câble sans s'en apercevoir en faisant une intervention en
salle machine ;-)
mysql_close ne ferme pas la connection persistante...
Et bien j'ai appris quelque chose aujourd'hui, il me semblait que justement le piège était qu'elle le faisait donc qu'il fallait surtout "oublier" de l'appeler. Changement récent ? Bref.
ben alors, quand est ce que cette connection se ferme ?? (elle se ferme bien un jour non ??)
Quatre acteurs peuvent fermer la socket si on est en base distante, trois sinon.
Le moteur Zend, détectant que cette socket n'a pas été utilisée depuis longtemps, doit probablement pouvoir la zapper. S'il ne le fait pas, il doit en être techniquement capable en tous cas. Au dessus, le process apache ou le serveur multithread peut décider de mettre fin au process/thread. La base de données peut elle aussi décider que l'inactivité a suffisement duré et mettre fin à la connexion.
Si on est en base distante, les équipements réseau, qui disposent souvent de deux temps de session (le temps total et le temps d'inactivité) peuvent couper la socket.
Et enfin, n'oublions pas le cas classique de l'être humain moyen qui débranche un câble sans s'en apercevoir en faisant une intervention en salle machine ;-)
a++ JG
El NiKo
john gallet a exprimé avec précision :
Le moteur Zend, détectant que cette socket n'a pas été utilisée depuis longtemps, doit probablement pouvoir la zapper. S'il ne le fait pas, il doit en être techniquement capable en tous cas. Au dessus, le process apache ou le serveur multithread peut décider de mettre fin au process/thread. La base de données peut elle aussi décider que l'inactivité a suffisement duré et mettre fin à la connexion.
ok mais bon ils decident pas ca tout seul !!??
il y a forcement un parametre qque part non ??!
merci
-- El NiKo (--: // :--)
supprimer "EnleveR" et " SpaM" pour répondre dans ma BAL
john gallet a exprimé avec précision :
Le moteur Zend, détectant que cette socket n'a pas été utilisée depuis
longtemps, doit probablement pouvoir la zapper. S'il ne le fait
pas, il doit en être techniquement capable en tous cas. Au dessus, le
process apache ou le serveur multithread peut décider de mettre fin au
process/thread. La base de données peut elle aussi décider que
l'inactivité a suffisement duré et mettre fin à la connexion.
ok mais bon ils decident pas ca tout seul !!??
il y a forcement un parametre qque part non ??!
merci
--
El NiKo (--: // :--)
EnleveRnickleeSpaM@free.fr
supprimer "EnleveR" et " SpaM" pour répondre dans ma BAL
Le moteur Zend, détectant que cette socket n'a pas été utilisée depuis longtemps, doit probablement pouvoir la zapper. S'il ne le fait pas, il doit en être techniquement capable en tous cas. Au dessus, le process apache ou le serveur multithread peut décider de mettre fin au process/thread. La base de données peut elle aussi décider que l'inactivité a suffisement duré et mettre fin à la connexion.
ok mais bon ils decident pas ca tout seul !!??
il y a forcement un parametre qque part non ??!
merci
-- El NiKo (--: // :--)
supprimer "EnleveR" et " SpaM" pour répondre dans ma BAL
john gallet
Re,
ok mais bon ils decident pas ca tout seul !!?? A part une éventuelle intervention du Dieu Root (ou de Saint Bill) je ne
vois pas qui d'autre pourrait décider à leur place...
il y a forcement un parametre qque part non ??! Autant que d'acteurs (qui n'ont aucun dialogue entre eux à ce sujet) et
encore, pas nécessairement facilement paramétrable directement. Par exemple, pour qu'apache décide de tuer un de ses process fils, il y a moult (1) raisons de le faire.
Bref, comme indiqué dans http://fr.php.net/manual/en/features.persistent-connections.php c'est exactement comme les non persistantes pour le développeur et ça se débrouille tout seul.
(1) (rappelons que moult est un adverbe donc invariable)
a++ JG
Re,
ok mais bon ils decident pas ca tout seul !!??
A part une éventuelle intervention du Dieu Root (ou de Saint Bill) je ne
vois pas qui d'autre pourrait décider à leur place...
il y a forcement un parametre qque part non ??!
Autant que d'acteurs (qui n'ont aucun dialogue entre eux à ce sujet) et
encore, pas nécessairement facilement paramétrable directement. Par
exemple, pour qu'apache décide de tuer un de ses process fils, il y a
moult (1) raisons de le faire.
Bref, comme indiqué dans
http://fr.php.net/manual/en/features.persistent-connections.php c'est
exactement comme les non persistantes pour le développeur et ça se
débrouille tout seul.
(1) (rappelons que moult est un adverbe donc invariable)
ok mais bon ils decident pas ca tout seul !!?? A part une éventuelle intervention du Dieu Root (ou de Saint Bill) je ne
vois pas qui d'autre pourrait décider à leur place...
il y a forcement un parametre qque part non ??! Autant que d'acteurs (qui n'ont aucun dialogue entre eux à ce sujet) et
encore, pas nécessairement facilement paramétrable directement. Par exemple, pour qu'apache décide de tuer un de ses process fils, il y a moult (1) raisons de le faire.
Bref, comme indiqué dans http://fr.php.net/manual/en/features.persistent-connections.php c'est exactement comme les non persistantes pour le développeur et ça se débrouille tout seul.
(1) (rappelons que moult est un adverbe donc invariable)
a++ JG
El NiKo
john gallet avait écrit le 27/01/2004 :
Bref, comme indiqué dans http://fr.php.net/manual/en/features.persistent-connections.php c'est exactement comme les non persistantes pour le développeur et ça se débrouille tout seul.
tres interessant...
j'ai du mal a comprendre "overhead" dont je n'ai trouvé aucune bonne reponse dans le dico
"Persistent connections are good if the overhead to create a link to your SQL server is high"
bon finallement, je n'ai pas de reponse.... on sait que les connections persistantes creent des connections qui ne sont pas closes par le programme mais on ne sait pas quand ces connections sont fermées reellement
en fait on pourrait repondre a ma question en repondant simplement a une autre : le fait de mettre en place des connections persistentes est il mauvais poour la securité ??
merci
-- El NiKo (--: // :--)
supprimer "EnleveR" et " SpaM" pour répondre dans ma BAL
john gallet avait écrit le 27/01/2004 :
Bref, comme indiqué dans
http://fr.php.net/manual/en/features.persistent-connections.php c'est
exactement comme les non persistantes pour le développeur et ça se
débrouille tout seul.
tres interessant...
j'ai du mal a comprendre "overhead" dont je n'ai trouvé aucune bonne
reponse dans le dico
"Persistent connections are good if the overhead to create a link to
your SQL server is high"
bon finallement, je n'ai pas de reponse....
on sait que les connections persistantes creent des connections qui ne
sont pas closes par le programme mais on ne sait pas quand ces
connections sont fermées reellement
en fait on pourrait repondre a ma question en repondant simplement a
une autre :
le fait de mettre en place des connections persistentes est il mauvais
poour la securité ??
merci
--
El NiKo (--: // :--)
EnleveRnickleeSpaM@free.fr
supprimer "EnleveR" et " SpaM" pour répondre dans ma BAL
Bref, comme indiqué dans http://fr.php.net/manual/en/features.persistent-connections.php c'est exactement comme les non persistantes pour le développeur et ça se débrouille tout seul.
tres interessant...
j'ai du mal a comprendre "overhead" dont je n'ai trouvé aucune bonne reponse dans le dico
"Persistent connections are good if the overhead to create a link to your SQL server is high"
bon finallement, je n'ai pas de reponse.... on sait que les connections persistantes creent des connections qui ne sont pas closes par le programme mais on ne sait pas quand ces connections sont fermées reellement
en fait on pourrait repondre a ma question en repondant simplement a une autre : le fait de mettre en place des connections persistentes est il mauvais poour la securité ??
merci
-- El NiKo (--: // :--)
supprimer "EnleveR" et " SpaM" pour répondre dans ma BAL
john gallet
Re,
j'ai du mal a comprendre "overhead" dont je n'ai trouvé aucune bonne reponse dans le dico
Temps inutile pour l'application passé à attendre la disponibilité d'une ressource. Se connecter à sa base de données, ça prend du temps. S'il est faible, pas grave. S'il est important parce qu'elle répond lentement à cette demande, ça peut améliorer les perfs que d'y rester connecté.
on sait que les connections persistantes creent des connections qui ne sont pas closes par le programme mais on ne sait pas quand ces connections sont fermées reellement C'est pas ton problème de développeur, en effet.
en fait on pourrait repondre a ma question en repondant simplement a une autre : le fait de mettre en place des connections persistentes est il mauvais poour la securité ??
Pas plus ou pas moins que les non persistantes, c'est le même chose sur le fond. Maintenant qu'est-ce qu'on appelle "sécurité" ?
a++ JG
Re,
j'ai du mal a comprendre "overhead" dont je n'ai trouvé aucune bonne
reponse dans le dico
Temps inutile pour l'application passé à attendre la disponibilité d'une
ressource. Se connecter à sa base de données, ça prend du temps. S'il
est faible, pas grave. S'il est important parce qu'elle répond lentement
à cette demande, ça peut améliorer les perfs que d'y rester connecté.
on sait que les connections persistantes creent des connections qui ne
sont pas closes par le programme mais on ne sait pas quand ces
connections sont fermées reellement
C'est pas ton problème de développeur, en effet.
en fait on pourrait repondre a ma question en repondant simplement a
une autre :
le fait de mettre en place des connections persistentes est il mauvais
poour la securité ??
Pas plus ou pas moins que les non persistantes, c'est le même chose sur
le fond. Maintenant qu'est-ce qu'on appelle "sécurité" ?
j'ai du mal a comprendre "overhead" dont je n'ai trouvé aucune bonne reponse dans le dico
Temps inutile pour l'application passé à attendre la disponibilité d'une ressource. Se connecter à sa base de données, ça prend du temps. S'il est faible, pas grave. S'il est important parce qu'elle répond lentement à cette demande, ça peut améliorer les perfs que d'y rester connecté.
on sait que les connections persistantes creent des connections qui ne sont pas closes par le programme mais on ne sait pas quand ces connections sont fermées reellement C'est pas ton problème de développeur, en effet.
en fait on pourrait repondre a ma question en repondant simplement a une autre : le fait de mettre en place des connections persistentes est il mauvais poour la securité ??
Pas plus ou pas moins que les non persistantes, c'est le même chose sur le fond. Maintenant qu'est-ce qu'on appelle "sécurité" ?
a++ JG
Shrom
"john gallet" a écrit dans le message de news:
en fait on pourrait repondre a ma question en repondant simplement a une autre : le fait de mettre en place des connections persistentes est il mauvais poour la securité ??
Pas plus ou pas moins que les non persistantes, c'est le même chose sur le fond. Maintenant qu'est-ce qu'on appelle "sécurité" ?
Ce n'est pas tant au niveau sécurité de l'application qu'il faut raisonner, mais plutôt en terme de configuration d'Apache et du SGBD.
Prenons un SGBD configuré pour accepter 5 connexions simulatnées. Apache, pour répondre aux requêtes HTTP, forke, c'est à dire qu'il se lance x fois en mémoire. Mettons qu'il le fasse 10 fois au démarrage, il y a donc 10 instances d'Apache qui peuvent répondre aux requêtes HTTP. Chaque page du site nécessite une connexion au SGBD ( ce qui est fréquent ). Les 5 premières instances d'Apache pourront créer la connexion persistante ( 5 connexions ) les 5 instances suivantes renverront invariablement une erreur puisqu'il n'y a plus possibilité de se connecter au SGBD et que les différentes instances d'Apache ne peuvent se partager les ressources, les 5 connexions autorisées sont déjà prises.
Tirer de la documentation de PHP: "Warning. Using persistent connections can require a bit of tuning of your Apache and MySQL configurations to ensure that you do not exceed the number of connections allowed by MySQL."
Ceci est bien sûr vrai pour tous les SGBD.
Conclusion: il faut que le nombre de connexions autorisées au SGBD soit au moins égal au nombre maximum de forks qu'Apache peut faire ce qui peut monter très haut en cas de forte charge du serveur.
Une meilleure solution est d'utiliser un pool de connexions genre SQLRelay.
"john gallet" <john.gallet@wanadoo.fr> a écrit dans le message de
news:40165BBA.BEE19A76@wanadoo.fr...
en fait on pourrait repondre a ma question en repondant simplement a
une autre :
le fait de mettre en place des connections persistentes est il mauvais
poour la securité ??
Pas plus ou pas moins que les non persistantes, c'est le même chose sur
le fond. Maintenant qu'est-ce qu'on appelle "sécurité" ?
Ce n'est pas tant au niveau sécurité de l'application qu'il faut raisonner,
mais plutôt en terme de configuration d'Apache et du SGBD.
Prenons un SGBD configuré pour accepter 5 connexions simulatnées.
Apache, pour répondre aux requêtes HTTP, forke, c'est à dire qu'il se lance
x fois en mémoire. Mettons qu'il le fasse 10 fois au démarrage, il y a donc
10 instances d'Apache qui peuvent répondre aux requêtes HTTP.
Chaque page du site nécessite une connexion au SGBD ( ce qui est fréquent ).
Les 5 premières instances d'Apache pourront créer la connexion persistante
( 5 connexions ) les 5 instances suivantes renverront invariablement une
erreur puisqu'il n'y a plus possibilité de se connecter au SGBD et que les
différentes instances d'Apache ne peuvent se partager les ressources, les 5
connexions autorisées sont déjà prises.
Tirer de la documentation de PHP:
"Warning.
Using persistent connections can require a bit of tuning of your Apache and
MySQL configurations to ensure that you do not exceed the number of
connections allowed by MySQL."
Ceci est bien sûr vrai pour tous les SGBD.
Conclusion: il faut que le nombre de connexions autorisées au SGBD soit au
moins égal au nombre maximum de forks qu'Apache peut faire ce qui peut
monter très haut en cas de forte charge du serveur.
Une meilleure solution est d'utiliser un pool de connexions genre SQLRelay.
en fait on pourrait repondre a ma question en repondant simplement a une autre : le fait de mettre en place des connections persistentes est il mauvais poour la securité ??
Pas plus ou pas moins que les non persistantes, c'est le même chose sur le fond. Maintenant qu'est-ce qu'on appelle "sécurité" ?
Ce n'est pas tant au niveau sécurité de l'application qu'il faut raisonner, mais plutôt en terme de configuration d'Apache et du SGBD.
Prenons un SGBD configuré pour accepter 5 connexions simulatnées. Apache, pour répondre aux requêtes HTTP, forke, c'est à dire qu'il se lance x fois en mémoire. Mettons qu'il le fasse 10 fois au démarrage, il y a donc 10 instances d'Apache qui peuvent répondre aux requêtes HTTP. Chaque page du site nécessite une connexion au SGBD ( ce qui est fréquent ). Les 5 premières instances d'Apache pourront créer la connexion persistante ( 5 connexions ) les 5 instances suivantes renverront invariablement une erreur puisqu'il n'y a plus possibilité de se connecter au SGBD et que les différentes instances d'Apache ne peuvent se partager les ressources, les 5 connexions autorisées sont déjà prises.
Tirer de la documentation de PHP: "Warning. Using persistent connections can require a bit of tuning of your Apache and MySQL configurations to ensure that you do not exceed the number of connections allowed by MySQL."
Ceci est bien sûr vrai pour tous les SGBD.
Conclusion: il faut que le nombre de connexions autorisées au SGBD soit au moins égal au nombre maximum de forks qu'Apache peut faire ce qui peut monter très haut en cas de forte charge du serveur.
Une meilleure solution est d'utiliser un pool de connexions genre SQLRelay.
