On Tue, Nov 6, 2012 at 1:31 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen <markokr@gmail.com> wrote:
>> On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
>>> On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries
>>> (like "select 1;" or "set timezone...") against 2 instances of
>>> pgbouncer, I get nearly twice the throughput as if I use only one
>>> instance.
>>>
>>> A rather odd workload, maybe, but it does seem to be similar to the
>>> one that started this thread.
>>
>> Every-connection-is-busy is pessimal workload for pgbouncer,
>> as it has nothing useful to contribute to setup, just overhead.
>
> It still has something to contribute if connections are made and
> broken too often (pgbench -C type workload), as seems to be the case
> here.
I did not notice -C in your message above.
In such case, in a practical, non-pgbench workload, you should
move pgbouncer to same machine as app, so any overhead
is just CPU, spread over all app instances, and does not
include network latency.
> If he can get an application-side pooler (or perhaps just a change in
> configuration) such that the connections are not made and broken so
> often, then removing pgbouncer from the loop would probably be a win.
Yes, if app has good pooling, there is less use for pgbouncer.
In any case, only long connections should go over network.
--
marko
