From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> |
Cc: | "Postgresql Performance" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: ProcArrayLock (The Saga continues) |
Date: | 2008-05-30 00:19:11 |
Message-ID: | 87hccgy77k.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> writes:
> Note with this no think time concept, each clients can be about 75% CPU busy
> from what I observed. running it I found the clients scaling up saturates at
> about 60 now (compared to 500 from the original test). The peak throughput was
> at about 50 users (using synchrnous_commit=off)
So to get the maximum throughput on the benchmark with think times you want to
aggregate the clients about 10:1 with a connection pooler or some middleware
layer of some kind, it seems.
It's still interesting to find the choke points for large numbers of
connections. But I think not because it's limiting your benchmark results --
that would be better addressed by using fewer connections -- just for the sake
of knowing where problems loom on the horizon.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
From | Date | Subject | |
---|---|---|---|
Next Message | Vlad Arkhipov | 2008-05-30 11:02:41 | Statistics issue |
Previous Message | Jignesh K. Shah | 2008-05-29 22:08:10 | ProcArrayLock (The Saga continues) |