From: Kevin Grittner <kgrittn@mail.com>
To: sthomas@optionshouse.com
Cc: Catalin Iacob <iacobcatalin@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: How to keep queries low latency as concurrency increases
Date: Tue, 30 Oct 2012 16:07:42 -0400
Message-ID: <20121030200742.306930@gmx.com> (raw)
Shaun Thomas wrote:
> On 10/30/2012 06:55 AM, Kevin Grittner wrote:
>> Is there a good transaction-based connection pooler in Python?
>> You're better off with a good pool built in to the client
>> application than with a good pool running as a separate process
>> between the client and the database, IMO.
>
> Could you explain this a little more? My experience is almost
> always the exact opposite, especially in large clusters that may
> have dozens of servers all hitting the same database. A
> centralized pool has much less duplication and can serve from a
> smaller pool than having 12 servers each have 25 connections
> reserved in their own private pool or something.
>
> I mean... a pool is basically a proxy server. I don't have 12
> individual proxy servers for 12 webservers.
Sure, if you have multiple web servers and they are not routing
their database requests through a common "model" layer, an external
pooler would make sense. Most of the time I've dealt either with one
web server or multiple servers routing requests at the transaction
level to a single JVM which ran the logic of the transaction --
either of which is a good place to have a connection pool. A dozen
different JVMs all making JDBC requests does kind of beg for an
external layer to concentrate the requests; if it isn't something
that's running the transaction layer, a connection pooler there
would be good.
-Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: kgrittn@mail.com, sthomas@optionshouse.com, iacobcatalin@gmail.com
Subject: Re: How to keep queries low latency as concurrency increases
In-Reply-To: <20121030200742.306930@gmx.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox