bonjour ou bonsoir,
je me pose quelques questions quant à la distribution des instances
de Connection au sein d'une webapp constituée de servlets, pages jsp...
jusqu'ici, j'en étais resté à la solution d'un singleton encapsulant
une unique connexion pour toute mon appli, mais cela me pose quelques
problèmes quant au renouvellement de ladite connexion (au bout d'un
moment, le lien avec mon sgbd se perd)
j'ai envisagé d'utiliser un pool de connexion, mais ca m'a amené a me
poser la question du nombre de connexions ; vaut il mieux :
- une seule connexion pour toute l'appli
- une connexion par session (ca me parait pas tres raisonnable)
- une connexion 'versatile', ouverte et fermée à chaque utilisation ;
outre le fait que ca implique l'utilisation d'un pool pour limiter les
temps de connexion, cela peut amener a utiliser énormément de
connexions pour certains traitements (par ex, une itération sur un
resultset qui appelle la création d'une instance d'une classe qui utilise
elle meme une connexion, etc...)
- d'autres solutions ?
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
Emmanuel Bourg
En général la taille maximale du pool correspond au nombre de requê tes simultanées que ton application doit servir. Par exemple si tu estimes que tu auras à tout moment 200 utilisateurs (ou sessions) qui chargent une nouvelle page toutes les 10 secondes avec un temps de traitement de l'ordre d'une seconde, il te faudra un pool de 20 connexions.
Tu peux aussi procéder par essais successifs, en prenant une taille de pool modeste et en augmentant le plafond à chaque fois que la limite es t atteinte. Tu finiras par converger vers la bonne valeur pour ton application.
Emmanuel
Joe wrote:
bonjour ou bonsoir, je me pose quelques questions quant à la distribution des instances de Connection au sein d'une webapp constituée de servlets, pages jsp. ..
jusqu'ici, j'en étais resté à la solution d'un singleton encapsul ant une unique connexion pour toute mon appli, mais cela me pose quelques problèmes quant au renouvellement de ladite connexion (au bout d'un moment, le lien avec mon sgbd se perd)
j'ai envisagé d'utiliser un pool de connexion, mais ca m'a amené a me poser la question du nombre de connexions ; vaut il mieux : - une seule connexion pour toute l'appli - une connexion par session (ca me parait pas tres raisonnable) - une connexion 'versatile', ouverte et fermée à chaque utilisation ; outre le fait que ca implique l'utilisation d'un pool pour limiter les temps de connexion, cela peut amener a utiliser énormément de connexions pour certains traitements (par ex, une itération sur un resultset qui appelle la création d'une instance d'une classe qui uti lise elle meme une connexion, etc...) - d'autres solutions ?
merci d'avance pour vos retours et conseils joe
En général la taille maximale du pool correspond au nombre de requê tes
simultanées que ton application doit servir. Par exemple si tu estimes
que tu auras à tout moment 200 utilisateurs (ou sessions) qui chargent
une nouvelle page toutes les 10 secondes avec un temps de traitement de
l'ordre d'une seconde, il te faudra un pool de 20 connexions.
Tu peux aussi procéder par essais successifs, en prenant une taille de
pool modeste et en augmentant le plafond à chaque fois que la limite es t
atteinte. Tu finiras par converger vers la bonne valeur pour ton
application.
Emmanuel
Joe wrote:
bonjour ou bonsoir,
je me pose quelques questions quant à la distribution des instances
de Connection au sein d'une webapp constituée de servlets, pages jsp. ..
jusqu'ici, j'en étais resté à la solution d'un singleton encapsul ant
une unique connexion pour toute mon appli, mais cela me pose quelques
problèmes quant au renouvellement de ladite connexion (au bout d'un
moment, le lien avec mon sgbd se perd)
j'ai envisagé d'utiliser un pool de connexion, mais ca m'a amené a me
poser la question du nombre de connexions ; vaut il mieux :
- une seule connexion pour toute l'appli
- une connexion par session (ca me parait pas tres raisonnable)
- une connexion 'versatile', ouverte et fermée à chaque utilisation ;
outre le fait que ca implique l'utilisation d'un pool pour limiter les
temps de connexion, cela peut amener a utiliser énormément de
connexions pour certains traitements (par ex, une itération sur un
resultset qui appelle la création d'une instance d'une classe qui uti lise
elle meme une connexion, etc...)
- d'autres solutions ?
En général la taille maximale du pool correspond au nombre de requê tes simultanées que ton application doit servir. Par exemple si tu estimes que tu auras à tout moment 200 utilisateurs (ou sessions) qui chargent une nouvelle page toutes les 10 secondes avec un temps de traitement de l'ordre d'une seconde, il te faudra un pool de 20 connexions.
Tu peux aussi procéder par essais successifs, en prenant une taille de pool modeste et en augmentant le plafond à chaque fois que la limite es t atteinte. Tu finiras par converger vers la bonne valeur pour ton application.
Emmanuel
Joe wrote:
bonjour ou bonsoir, je me pose quelques questions quant à la distribution des instances de Connection au sein d'une webapp constituée de servlets, pages jsp. ..
jusqu'ici, j'en étais resté à la solution d'un singleton encapsul ant une unique connexion pour toute mon appli, mais cela me pose quelques problèmes quant au renouvellement de ladite connexion (au bout d'un moment, le lien avec mon sgbd se perd)
j'ai envisagé d'utiliser un pool de connexion, mais ca m'a amené a me poser la question du nombre de connexions ; vaut il mieux : - une seule connexion pour toute l'appli - une connexion par session (ca me parait pas tres raisonnable) - une connexion 'versatile', ouverte et fermée à chaque utilisation ; outre le fait que ca implique l'utilisation d'un pool pour limiter les temps de connexion, cela peut amener a utiliser énormément de connexions pour certains traitements (par ex, une itération sur un resultset qui appelle la création d'une instance d'une classe qui uti lise elle meme une connexion, etc...) - d'autres solutions ?
merci d'avance pour vos retours et conseils joe
Joe
On Mon, 20 Oct 2003 11:50:54 +0200, Emmanuel Bourg wrote:
En général la taille maximale du pool correspond au nombre de requêtes simultanées que ton application doit servir. Par exemple si tu estimes que tu auras à tout moment 200 utilisateurs (ou sessions) qui chargent une nouvelle page toutes les 10 secondes avec un temps de traitement de l'ordre d'une seconde, il te faudra un pool de 20 connexions.
celà signifie t'il donc que, pour toi, je dois définir une connexion par
"page" ? via un bean de type request ? ca rappelle la façon de faire de php, mais est ce la méthode la plus appropriée dans le cadre d'une archi J2EE ?
joe
On Mon, 20 Oct 2003 11:50:54 +0200, Emmanuel Bourg wrote:
En général la taille maximale du pool correspond au nombre de requêtes
simultanées que ton application doit servir. Par exemple si tu estimes
que tu auras à tout moment 200 utilisateurs (ou sessions) qui chargent
une nouvelle page toutes les 10 secondes avec un temps de traitement de
l'ordre d'une seconde, il te faudra un pool de 20 connexions.
celà signifie t'il donc que, pour toi, je dois définir une connexion par
"page" ? via un bean de type request ? ca rappelle la façon de faire de
php, mais est ce la méthode la plus appropriée dans le cadre d'une archi
J2EE ?
On Mon, 20 Oct 2003 11:50:54 +0200, Emmanuel Bourg wrote:
En général la taille maximale du pool correspond au nombre de requêtes simultanées que ton application doit servir. Par exemple si tu estimes que tu auras à tout moment 200 utilisateurs (ou sessions) qui chargent une nouvelle page toutes les 10 secondes avec un temps de traitement de l'ordre d'une seconde, il te faudra un pool de 20 connexions.
celà signifie t'il donc que, pour toi, je dois définir une connexion par
"page" ? via un bean de type request ? ca rappelle la façon de faire de php, mais est ce la méthode la plus appropriée dans le cadre d'une archi J2EE ?
joe
Emmanuel Bourg
Joe wrote:
celà signifie t'il donc que, pour toi, je dois définir une connexio n par "page" ? via un bean de type request ? ca rappelle la façon de faire de php, mais est ce la méthode la plus appropriée dans le cadre d'une archi J2EE ?
Non pas du tout, une connexion du pool peut être utilisée pour n'impo rte quelle page de l'application. Question annexe, tu utilises quoi pour ton pool de connexions ? J'ai peur que tu essayes de mettre les connexions en session, rassure moi :)
Emmanuel
Joe wrote:
celà signifie t'il donc que, pour toi, je dois définir une connexio n par
"page" ? via un bean de type request ? ca rappelle la façon de faire de
php, mais est ce la méthode la plus appropriée dans le cadre d'une archi
J2EE ?
Non pas du tout, une connexion du pool peut être utilisée pour n'impo rte
quelle page de l'application. Question annexe, tu utilises quoi pour ton
pool de connexions ? J'ai peur que tu essayes de mettre les connexions
en session, rassure moi :)
celà signifie t'il donc que, pour toi, je dois définir une connexio n par "page" ? via un bean de type request ? ca rappelle la façon de faire de php, mais est ce la méthode la plus appropriée dans le cadre d'une archi J2EE ?
Non pas du tout, une connexion du pool peut être utilisée pour n'impo rte quelle page de l'application. Question annexe, tu utilises quoi pour ton pool de connexions ? J'ai peur que tu essayes de mettre les connexions en session, rassure moi :)
Emmanuel
Joe
celà signifie t'il donc que, pour toi, je dois définir une connexion parr
"page" ? via un bean de type request ? ca rappelle la façon de faire de php, mais est ce la méthode la plus appropriée dans le cadre d'une archi J2EE ?
Non pas du tout, une connexion du pool peut être utilisée pour n'importe quelle page de l'application. Question annexe, tu utilises quoi pour ton pool de connexions ? J'ai peur que tu essayes de mettre les connexions en session, rassure moi :)
non non rassure toi, pas de connexion en session en vue :-) comme je te le
disais, jusqu'ici j'utilisais un singleton pour mon appli
si je pose ma question d'un point de vue plus général, ca pourrait etre : qu'est ce qui incite a utiliser plusieurs connexions ? finalement, hormis mon problème de timeout, mon appli fonctionnait bien avec une seule connexion ; je vois bien qu'il doit y avoir des raisons tres objectives qui font utiliser X connexions, mais je n'ai jamais réussi a lire pourquoi : prob de performances, ou autre...?
joe
celà signifie t'il donc que, pour toi, je dois définir une
connexion parr
"page" ? via un bean de type request ? ca rappelle la façon de faire
de php, mais est ce la méthode la plus appropriée dans le cadre d'une
archi J2EE ?
Non pas du tout, une connexion du pool peut être utilisée pour
n'importe quelle page de l'application. Question annexe, tu utilises
quoi pour ton pool de connexions ? J'ai peur que tu essayes de mettre
les connexions en session, rassure moi :)
non non rassure toi, pas de connexion en session en vue :-) comme je te le
disais, jusqu'ici j'utilisais un singleton pour mon appli
si je pose ma question d'un point de vue plus général, ca pourrait etre
: qu'est ce qui incite a utiliser plusieurs connexions ? finalement,
hormis mon problème de timeout, mon appli fonctionnait bien avec une
seule connexion ; je vois bien qu'il doit y avoir des raisons tres
objectives qui font utiliser X connexions, mais je n'ai jamais réussi a
lire pourquoi : prob de performances, ou autre...?
celà signifie t'il donc que, pour toi, je dois définir une connexion parr
"page" ? via un bean de type request ? ca rappelle la façon de faire de php, mais est ce la méthode la plus appropriée dans le cadre d'une archi J2EE ?
Non pas du tout, une connexion du pool peut être utilisée pour n'importe quelle page de l'application. Question annexe, tu utilises quoi pour ton pool de connexions ? J'ai peur que tu essayes de mettre les connexions en session, rassure moi :)
non non rassure toi, pas de connexion en session en vue :-) comme je te le
disais, jusqu'ici j'utilisais un singleton pour mon appli
si je pose ma question d'un point de vue plus général, ca pourrait etre : qu'est ce qui incite a utiliser plusieurs connexions ? finalement, hormis mon problème de timeout, mon appli fonctionnait bien avec une seule connexion ; je vois bien qu'il doit y avoir des raisons tres objectives qui font utiliser X connexions, mais je n'ai jamais réussi a lire pourquoi : prob de performances, ou autre...?
joe
Emmanuel Bourg
Joe wrote:
non non rassure toi, pas de connexion en session en vue :-) comme je te le disais, jusqu'ici j'utilisais un singleton pour mon appli
si je pose ma question d'un point de vue plus général, ca pourrait etre : qu'est ce qui incite a utiliser plusieurs connexions ? finalement, hormis mon problème de timeout, mon appli fonctionnait bien avec une seule connexion ; je vois bien qu'il doit y avoir des raisons tres objectives qui font utiliser X connexions, mais je n'ai jamais réuss i a lire pourquoi : prob de performances, ou autre...?
joe
C'est essentiellement une question de performances. Tu ne peux pas exécuter deux requêtes en même temps sur la même connexion. Tant que tu n'as qu'un seul accès à la base à tout moment ça ne pose pas de p roblème comme tu as pu le constater. Si la charge augmentait tu commencerais à observer des temps d'attente plus ou moins long selon la complexité des traitements.
Ce goulot d'étranglement ne justifie pas l'utilisation d'un pool en soi , après tout on pourrait créer une nouvelle connexion à chaque accè s à la base. Cependant la création d'une connexion prend beaucoup plus de temp s que d'aller en chercher une dans le pool. Quand l'application commence à être chargée l'impact sur les performances devient significatif.
Emmanuel
Joe wrote:
non non rassure toi, pas de connexion en session en vue :-) comme je te le
disais, jusqu'ici j'utilisais un singleton pour mon appli
si je pose ma question d'un point de vue plus général, ca pourrait etre
: qu'est ce qui incite a utiliser plusieurs connexions ? finalement,
hormis mon problème de timeout, mon appli fonctionnait bien avec une
seule connexion ; je vois bien qu'il doit y avoir des raisons tres
objectives qui font utiliser X connexions, mais je n'ai jamais réuss i a
lire pourquoi : prob de performances, ou autre...?
joe
C'est essentiellement une question de performances. Tu ne peux pas
exécuter deux requêtes en même temps sur la même connexion. Tant que tu
n'as qu'un seul accès à la base à tout moment ça ne pose pas de p roblème
comme tu as pu le constater. Si la charge augmentait tu commencerais à
observer des temps d'attente plus ou moins long selon la complexité des
traitements.
Ce goulot d'étranglement ne justifie pas l'utilisation d'un pool en soi ,
après tout on pourrait créer une nouvelle connexion à chaque accè s à la
base. Cependant la création d'une connexion prend beaucoup plus de temp s
que d'aller en chercher une dans le pool. Quand l'application commence à
être chargée l'impact sur les performances devient significatif.
non non rassure toi, pas de connexion en session en vue :-) comme je te le disais, jusqu'ici j'utilisais un singleton pour mon appli
si je pose ma question d'un point de vue plus général, ca pourrait etre : qu'est ce qui incite a utiliser plusieurs connexions ? finalement, hormis mon problème de timeout, mon appli fonctionnait bien avec une seule connexion ; je vois bien qu'il doit y avoir des raisons tres objectives qui font utiliser X connexions, mais je n'ai jamais réuss i a lire pourquoi : prob de performances, ou autre...?
joe
C'est essentiellement une question de performances. Tu ne peux pas exécuter deux requêtes en même temps sur la même connexion. Tant que tu n'as qu'un seul accès à la base à tout moment ça ne pose pas de p roblème comme tu as pu le constater. Si la charge augmentait tu commencerais à observer des temps d'attente plus ou moins long selon la complexité des traitements.
Ce goulot d'étranglement ne justifie pas l'utilisation d'un pool en soi , après tout on pourrait créer une nouvelle connexion à chaque accè s à la base. Cependant la création d'une connexion prend beaucoup plus de temp s que d'aller en chercher une dans le pool. Quand l'application commence à être chargée l'impact sur les performances devient significatif.
Emmanuel
Joe
Ce goulot d'étranglement ne justifie pas l'utilisation d'un pool en soi, après tout on pourrait créer une nouvelle connexion à chaque accès à la base. Cependant la création d'une connexion prend beaucoup plus de temps que d'aller en chercher une dans le pool. Quand l'application commence à être chargée l'impact sur les performances devient significatif.
ok, merci beaucoup pour tes éclaircissements !
Ce goulot d'étranglement ne justifie pas l'utilisation d'un pool en soi,
après tout on pourrait créer une nouvelle connexion à chaque accès à la
base. Cependant la création d'une connexion prend beaucoup plus de temps
que d'aller en chercher une dans le pool. Quand l'application commence à
être chargée l'impact sur les performances devient significatif.
Ce goulot d'étranglement ne justifie pas l'utilisation d'un pool en soi, après tout on pourrait créer une nouvelle connexion à chaque accès à la base. Cependant la création d'une connexion prend beaucoup plus de temps que d'aller en chercher une dans le pool. Quand l'application commence à être chargée l'impact sur les performances devient significatif.
