Re: Rails et pgBouncer / pgPool

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Bertrand Paquet <bpaquet(at)octo(dot)com>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Rails et pgBouncer / pgPool
Date: 2011-01-28 12:52:34
Message-ID: 4D42BC12.4020902@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

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

Responses

Browse pgsql-fr-generale by date

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