MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: text/plain; format=flowed; charset=windows-1252
Date: Fri, 13 Mar 2009 08:38:39 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <C5DEE151.33BA%scott@richrelevance.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49BA53CF.4020702@sun.com>
References: <C5DEE151.33BA%scott@richrelevance.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)


Scott Carey wrote:
> On 3/12/09 11:37 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:
>
>
>     And again this is the third time I am saying.. the test users also
>     have some latency build up in them which is what generally is
>     exploited to get more users than number of CPUS on the system but
>     that's the point we want to exploit.. Otherwise if all new users
>     begin to do their job with no latency then we would need 6+
>     billion cpus to handle all possible users. Typically as an
>     administrator (System and database) I can only tweak/control
>     latencies within my domain, that is network, disk, cpu's etc and
>     those are what I am tweaking and coming to a *Configured*
>     environment and now trying to improve lock contentions/waits in
>     PostgreSQL so that we have an optimized setup.
>
> In general, I suggest that it is useful to run tests with a few 
> different types of pacing. Zero delay pacing will not have realistic 
> number of connections, but will expose bottlenecks that are universal, 
> and less controversial. Small latency (100ms to 1s) tests are easy to 
> make from the zero delay ones, and help expose problems with 
> connection count or other forms of ‘non-active’ concurrency. End-user 
> realistic delays are app specific, and useful with larger holistic 
> load tests (say, through the application interface). Generally, 
> running them in this order helps because at each stage you are adding 
> complexity. Based on your explanations, you’ve probably done much of 
> this so far and your approach sounds solid to me.
> If the first case fails (zero delay, smaller user count), there is no 
> way the others will pass.
>
>

I think I have done that before so I can do that again by running the 
users at 0 think time which will represent a "Connection pool" which is 
highly utilized" and test how big the connection pool can be before the 
throughput tanks.. This can be useful for App Servers which sets up 
connections pools of their own talking with PostgreSQL.

-Jignesh


-- 
Jignesh Shah           http://blogs.sun.com/jkshah  			
The New Sun Microsystems,Inc   http://sun.com/postgresql