Re: Rails et pgBouncer / pgPool

From: Bertrand Paquet <bpaquet(at)octo(dot)com>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Rails et pgBouncer / pgPool
Date: 2011-01-28 13:14:56
Message-ID: AANLkTi=jbKjY9vJaCvFuQzQ3OQeA17R_kBFaNCCaq9EE@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Oui, c'est beaucoup plus clair.

Merci pour ces explications, je vais donc installer un pooler partout.

Bertrand

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

> 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

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Stéphane A. Schildknecht 2011-01-28 13:20:15 Re: Rails et pgBouncer / pgPool
Previous Message Guillaume Lelarge 2011-01-28 13:13:37 Re: Rails et pgBouncer / pgPool