Re: Rails et pgBouncer / pgPool

Bonjour,

Je me permet de préciser quelques points soulevés par Guillaume, qui est
passé sur certains éléments par soucis didactiques je suppose :)

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> Le temps de création du processus peut très peu de temps (disons 200 ms
> pour avoir un exemple). Si la connexion dure plusieurs minutes, voire
> plusieurs heures comme cela peut être le cas avec pgAdmin ou pg_dump,
> 200 ms de connexion, c'est rien.

Dans le détail, la création d'un processus sur un unix moderne est assez
efficace ne pose pas de problème en soit. Les soucis viennent de
l'initialisation du processus par PostgreSQL, qui met en place un nombre
important de caches en mémoire pour la durée de la session (en gros,
tout ce qui concerne les accès aux catalogues systèmes).

> Interviennent dans ce cas les poolers de connexions.
>
> Ils se placent entre le client et le serveur PostgreSQL. Le client se
> connecte au pooler qui va faire la connexion à PostgreSQL. Lorsque le
> client se déconnecte, le pooler conserve la connexion à PostgreSQL pour
> pouvoir la réutiliser pour un autre client. Si bien que le deuxième
> client qui se connecte au pooler aura une connexion très rapide car la
> connexion à PostgreSQL est déjà faite. Pareil pour le troisième, le
> quatrième, etc.
>
> Les poolers n'ont pas le même problème de création de processus que
> PostgreSQL car soit ils ont déjà créé les processus dès le début (c'est
> le cas de pgpool) soit ils utilisent des threads (là, c'est pour pgbouncer).

Dans le cas de pgbouncer, le comportement réel du pool de connexion
dépend du paramétrage du "pooling_mode" qui est par défaut à la session,
et donc attribue une connexion serveur dédiée à chaque connexion
cliente. Le gain vient alors du fait qu'une connexion serveur peut être
« nettoyée » puis réutilisée, on gagne alors toutes les étapes
d'initialisation dont on parlait ci-dessus.

Le mode "transaction" est nettement plus aggressif et permet souvent de
bien meilleurs gains, mais il est nécessaire de bien valider le
comportement applicatif : cela ne fonctionne que si l'on ne dépend pas
des sessions PostgreSQL. La documentation de pgbouncer liste les points
à valider.

Ensuite, toujours dans le cas de pgbouncer, il n'utilise pas de thread à
ma connaissance, mais une programmation événementielle, profitant de
libevent. Il s'agit donc pour lui de simplement maintenir un ensemble
de machines à états, et de comprendre le protocole de communication de
PostgreSQL, sans jamais avoir à comprendre les données qui y transitent
(en particulier, il ne fait aucune analyse des requêtes SQL).

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support