Re: Proposal of tunable fix for scalability of 8.4 - Mailing list pgsql-performance

From Gregory Stark
Subject Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id 871vt1609r.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Proposal of tunable fix for scalability of 8.4  ("Jignesh K. Shah" <J.K.Shah@Sun.COM>)
Responses Re: Proposal of tunable fix for scalability of 8.4  ("Jignesh K. Shah" <J.K.Shah@Sun.COM>)
Re: Proposal of tunable fix for scalability of 8.4  (decibel <decibel@decibel.org>)
List pgsql-performance
"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:

> Scott Carey wrote:
>> On 3/12/09 11:37 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:
>>
>> 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
>
> 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.

Keep in mind when you do this that it's not interesting to test a number of
connections much larger than the number of processors you have. Once the
system reaches 100% cpu usage it would be a misconfigured connection pooler
that kept more than that number of connections open.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!

pgsql-performance by date:

Previous
From: "Jignesh K. Shah"
Date:
Subject: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Next
From: Gregory Stark
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4