On 3/12/09 10:09 AM, "Gregory Stark" <st...@enterprisedb.com> wrote:


Ram-resident use cases are entirely valid and worth testing, but in those use
cases you would want to have about as many processes as you have processes.

Within a factor of two or so, yes.  However, where in his results does it show 
that there are 1000 active postgres connections?  What if the test script is 
the most valid type:  emulating application compute and sleep time between 
requests?

What it is showing is “Users”.  We don’t know the relationship between those 
and active postgres connections.  Your contention is ONLY valid for active 
postgres processes.

Yes, the test could be invalid if it is artificially making all users bang up 
on the same locks by for example, having them all access the same rows.  
However, if this was what explains the results around the user count being 
about equal to CPU threads, then the throughput would have stopped growing 
around where the user count got near the CPU threads, not after a couple 
thousand.

The ‘fingerprint’ of this load test — linear scaling up to a point, then a peak 
and dropoff — is one of a test with paced users not one with artificial locking 
affecting results at low user counts.  More data would help, but artificial 
lock contention with low user count would have shown up at low user count, not 
after 1000 users.  There are some difficult to manipulate ways to fake this out 
(which is why CPU% and context switch rate data would help).  This is most 
likely a ‘paced user’ profile.

The use case where having larger number of connections than processors makes
sense is when they're blocked on disk i/o (or network i/o or whatever else
other than cpu).

Um, or are idle in a connection pool for 100ms.  There is no such thing as a 
perfectly sized connection pool.  And there is nothing wrong with some idle 
connections.


And as always the question would be whether the code designed for this
misconfigured setup is worth the maintenance effort if it's not helping
properly configured setups.

Now you are just assuming its misconfigured.  I’d wager quite a bit it helps 
properly configured setups too so long as they have lots of hardware threads.



Reply via email to