Re: Rails et pgBouncer / pgPool

Merci pour cette réponse.

Cependant, je ne comprends pas bien.

Est ce que cela signifie que l'établissement de la connexion entre Rails et
pgBouncer est plus légère que l'établissement d'une connexion entre Rails et
PostgreSQL ?

Si oui, ok, cela me parait être une très bonne explication.
Sinon, l'appli Rails établit toujours autant de connexion, que ca soit sur
pgBouncer que sur PostgreSQL, donc cela devrait faire pareil.

Bertrand

2011/1/28 Guillaume Lelarge <guillaume(at)lelarge(dot)info>

> Bonjour,
>
> Le 28/01/2011 12:13, Bertrand Paquet a écrit :
> > [...]
> > Nous avons une application Ruby On Rails qui utilise une base de données
> > posgresql 8.4.
> >
> > Quand nous mettons un pooler de connexions (pgbouncer ou pgpool) entre
> > l'application Rails et Postgres, nous constatons un accroissement des
> > performances de l'ordre de 50%. Sans rien changer dans la config Rails au
> > niveau des pools de connexions ou autre.
> >
> > Nous sommes très contents de cet accroissement, mais nous aimerions bien
> > comprendre d'où cela vient. Voici les hypothèses que nous avons
> actuellement
> > :
> > - cache de requêtes au niveau du pooler ?
>
> Non. Il est possible d'avoir un cache de requêtes avec pgpool mais pas
> avec pgbouncer. Pour pgpool, il est désactivé par défaut.
>
> > - établissement de connexion moins couteuse entre Rails et le pooler
> > qu'entre Rails et la vraie base (authent) ?
>
> Ça devrait être le contraire car vous avez un étage supplémentaire.
>
> > - limitation du nombre de connexions ? le pooler limite le nb de
> connexions
> > réelles sur la base, donc Rails par défaut en ferait trop ?
> > - différence dans le maintien de la connexion entre Rails / pooler et
> Rails
> > / postgres ? (la vraie base déconnecte plus ?)
>
> Il y a de fortes chances que l'amélioration des performances que vous
> constatez est du au temps d'établissement de la connexion avec
> PostgreSQL seul.
>
> pgPool comme pgBouncer garde la connexion active avec PostgreSQL même si
> le client s'est déconnecté. Ce qui permet une connexion immédiate à la
> prochaine connexion.
>
> J'ai eu le cas chez un client où son outil se connectait pour exécuter
> très peu de requêtes. En gros, il y avait 300 ms pour ouvrir et fermer
> la connexion, et 30 ms pour l'exécution des requêtes. Du coup, la
> session durait 330 ms alors que les requêtes seules n'en prenaient que
> 30 ms. Du coup, avoir un pooler qui va garder la connexion active avec
> le serveur de bases de données est un facteur essentiel pour accélérer
> son application.
>
> Je pense que c'est ce qui explique l'amélioration des performances chez
> vous aussi.
>
>
> --
> Guillaume
> http://www.postgresql.fr
> http://dalibo.com
>