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

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 13:13:37
Message-ID: 4D42C101.4060302@lelarge.info (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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 ?
> 

Oui mais ce n'est pas la seule raison.

Lorsque vous faites une connexion à PostgreSQL à partir d'un client (que
ce soit une application Rails, pgAdmin, pg_dump, psql, etc), le serveur
PostgreSQL doit exécuter un fork, autrement dit créer un nouveau
processus qui sera en charge de la communication avec le client. Lors de
la déconnexion du client, le processus quitte.

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.

Prenons maintenant une application web qui doit s'exécuter très
rapidement pour ramener immédiatement l'information au gars derrière son
navigateur. Le temps de la session sera beaucoup plus court. Elle devra
même être inférieur à la seconde, sinon le gars va s'ennuyer avant de
récupérer sa page web. Dans ce cas, la durée de la connexion est un
facteur dont on aimerait bien se passer.

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).

J'espère avoir mieux expliqué cette fois-ci :)


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com

In response to

Responses

pgsql-fr-generale by date

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

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