Skip site navigation (1) Skip section navigation (2)

Re: Rails et pgBouncer / pgPool

From: Thomas Reiss <thomas(dot)reiss(at)interieur(dot)gouv(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Cc: bpaquet(at)octo(dot)com
Subject: Re: Rails et pgBouncer / pgPool
Date: 2011-01-28 13:10:03
Message-ID: 4D42C02B.1040108@interieur.gouv.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Bonjour,

Le coût d'une connexion à la base est essentiellement due au coût de 
création d'un processus côté serveur, avec un fork().

Si vous utilisez un pooler, celui-ci va démarrer un certain nombre de 
connexions à la base qu'il va maintenir tout le long de la vie du 
pooler. Vous n'aurez ainsi plus le coût de la création du processus serveur.

Cordialement,Thomas


Le 28/01/2011 13:58, Bertrand Paquet a écrit :
> 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 
> <mailto: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
>
>

In response to

pgsql-fr-generale by date

Next:From: Stéphane A. SchildknechtDate: 2011-01-28 13:12:32
Subject: Re: Rails et pgBouncer / pgPool
Previous:From: Bertrand PaquetDate: 2011-01-28 12:58:33
Subject: Re: Rails et pgBouncer / pgPool

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group