Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je voudrais savoir quels critères peut nous conduire à l'utilisation de pgPool-II?
Hormis les fonctionnalités de répartition de charge, de failover et de online-recovery, quelle situation demande de mettre en place du pooling de connexion?
Plus particulièrement, j'ai pu lire un article sur Dalibo qui disait qu'au delà de 1000 connexions concurrentes, il fallait envisager du pooling de connexion. Est ce toujours d'actualité pour la 9.3.4?
Si oui, quels est alors l'inconvénient de positionner un max_connections > 1000? Est ce un problème de gestion de la mémoire partagée ou autre?
Voici l'extrait sur http://www.dalibo.org/hs44_rapide_confi … postgresql:
Par défaut, il est à 100, ce qui est une valeur généralement correcte. Il ne faut pas hésiter à l'augmenter, tout en sachant que des valeurs supérieures à 1000 ne sont pas conseillées. Il vaudra mieux utiliser un pooler de connexions dans ce cas. Les deux disponibles pour PostgreSQL vous seront présentés dans le reste de ce hors-série.
Merci d'avance pour vos explications en espérant avoir été assez précis dans mes demandes.
Hors ligne
Préférez plutôt pgBouncer à pgPool-II. Sinon, il faut envisager du pooling de connexions quand la nombre de requêtes en parallèle dépasse les capacités du serveur. Un premier point de départ est d'estimer 10 à 20 requêtes en parallèles par cœur de processeur par exemple.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre réponse.
Pourquoi pgBouncer plutôt que pgPool-II?
Hors ligne
Parce que pgBouncer est plus léger et ne fait qu'une chose et bien : du pooling de connexion. pgPool-II a trop de fonctionnalités et sa gestion du pooling est moins bonne que pgBouncer.
Julien.
https://rjuju.github.io/
Hors ligne
Ok. j'avais déjà lu ce type de remarque sur pgBouncer.
Merci pour vos réponses et votre réactivité!
Hors ligne
Pages : 1
