From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Catalin Iacob <iacobcatalin(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: How to keep queries low latency as concurrency increases |
Date: | 2012-11-05 23:31:52 |
Message-ID: | CAMkU=1z_NyKv-jMLC2-Xe5z+H2X-cm2a=8aJgrgUmcDRq6a8Uw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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.
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.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2012-11-05 23:58:07 | Re: How to keep queries low latency as concurrency increases |
Previous Message | Marko Kreen | 2012-11-05 22:58:34 | Re: How to keep queries low latency as concurrency increases |