Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 865B66338A7
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 11 Mar 2009 19:27:24 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 12253-04
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 11 Mar 2009 19:27:17 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by mail.postgresql.org (Postfix) with ESMTP id B881F632C8D
	for <pgsql-performance@postgresql.org>;
	Wed, 11 Mar 2009 19:27:22 -0300 (ADT)
Received: from Courts-MTA by gwmta.wicourts.gov
	with Novell_GroupWise; Wed, 11 Mar 2009 17:27:21 -0500
Message-Id: <49B7F470.EE98.0025.0@wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 7.0.3 
Date: Wed, 11 Mar 2009 17:27:12 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: <pgsql-performance@postgresql.org>,
	"Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
References: <49B824DD.7090302@sun.com>
In-Reply-To: <49B824DD.7090302@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200903/106
X-Sequence-Number: 33028

>>> "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote: 
> Rerunning similar tests on a 64-thread UltraSPARC T2plus based
> server config
 
> (IO is not a problem... all in RAM .. no disks):
> Time:Users:Type:TPM: Response Time
> 60: 100: Medium Throughput: 10552.000 Avg Medium Resp: 0.006
> 120: 200: Medium Throughput: 22897.000 Avg Medium Resp: 0.006
> 180: 300: Medium Throughput: 33099.000 Avg Medium Resp: 0.009
> 240: 400: Medium Throughput: 44692.000 Avg Medium Resp: 0.007
> 300: 500: Medium Throughput: 56455.000 Avg Medium Resp: 0.007
> 360: 600: Medium Throughput: 67220.000 Avg Medium Resp: 0.008
> 420: 700: Medium Throughput: 77592.000 Avg Medium Resp: 0.009
> 480: 800: Medium Throughput: 87277.000 Avg Medium Resp: 0.011
> 540: 900: Medium Throughput: 98029.000 Avg Medium Resp: 0.012
> 600: 1000: Medium Throughput: 102547.000 Avg Medium Resp: 0.023
 
I'm wondering about the testing methodology.  If there is no I/O, I
wouldn't expect performance to improve after you have all the CPU
threads busy.  (OK, so there might be some brief blocking that would
make the optimal number of connections somewhat above 64, but 1000???)
 
What's the bottleneck which allows additional connections to improve
the throughput?  Network latency?
 
I'm a lot more interested in what's happening between 60 and 180 than
over 1000, personally.  If there was a RAID involved, I'd put it down
to better use of the numerous spindles, but when it's all in RAM it
makes no sense.
 
-Kevin