To: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Cc: "Postgresql Performance" <pgsql-performance@postgresql.org>
Subject: Re: ProcArrayLock (The Saga continues)
In-Reply-To: <483F294A.9040108@sun.com> (Jignesh K. Shah's message of "Thu\,
	29 May 2008 18\:08\:10 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <483F294A.9040108@sun.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Fri, 30 May 2008 01:19:11 +0100
Message-ID: <87hccgy77k.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Jignesh K. Shah" <J.K.Shah@Sun.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!