X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id EDC6E9FA5BA
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Sat,  3 Jun 2006 12:18:54 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 72378-10
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Sat,  3 Jun 2006 12:18:46 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from skunk.mtbrook.bozemanpass.com (unknown [69.145.82.195])
	by postgresql.org (Postfix) with ESMTP id C8FCC9FA311
	for <pgsql-performance@postgresql.org>;
	Sat,  3 Jun 2006 12:18:45 -0300 (ADT)
Received: from [69.145.82.253] (unknown [69.145.82.253])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id 22AEB6C8007
	for <pgsql-performance@postgresql.org>;
	Sat,  3 Jun 2006 08:18:45 -0700 (PDT)
Message-ID: <4481A856.7050907@boreham.org>
Date: Sat, 03 Jun 2006 09:18:46 -0600
From: David Boreham <david_list@boreham.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: scaling up postgres
References: <200606030931.k539V38Y007877@smtp2.planet.net.tn>
	<15971.1149347558@sss.pgh.pa.us>
In-Reply-To: <15971.1149347558@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------060302020507080308080300"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200606/24
X-Sequence-Number: 19381

This is a multi-part message in MIME format.
--------------060302020507080308080300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

>fzied@planet.tn writes:
>  
>
>>I'm using httperf/autobench for measurments and the best result I can get 
>>is that my system can handle a trafiic of almost 1600 New con/sec.
>>    
>>
>
>As per PFC's comment, if connections/sec is a bottleneck for you then
>the answer is to use persistent connections.  Launching a new backend
>is a fairly heavyweight operation in Postgres.  
>
I thought the OP was talking about HTTP connections/s. He didn't say if he
was using persistent database connections or not (obviously better if so).
If it were the case that his setup is new backend launch rate-limited, then
wouldn't the machine show CPU saturation ?  (he said it didn't).



--------------060302020507080308080300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:
<blockquote cite="mid15971.1149347558@sss.pgh.pa.us" type="cite">
  <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:fzied@planet.tn">fzied@planet.tn</a> writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I'm using httperf/autobench for measurments and the best result I can get 
is that my system can handle a trafiic of almost 1600 New con/sec.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
As per PFC's comment, if connections/sec is a bottleneck for you then
the answer is to use persistent connections.  Launching a new backend
is a fairly heavyweight operation in Postgres.  </pre>
</blockquote>
I thought the OP was talking about HTTP connections/s. He didn't say if
he<br>
was using persistent database connections or not (obviously better if
so).<br>
If it were the case that his setup is new backend launch rate-limited,
then <br>
wouldn't the machine show CPU saturation ?&nbsp; (he said it didn't).<br>
<br>
<br>
</body>
</html>

--------------060302020507080308080300--