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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-fr-generale by date

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