Re: Question on pgbench output

From: Tom Lane
Subject: Re: Question on pgbench output
Date: ,
Msg-id: 4665.1238946412@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Question on pgbench output  (Simon Riggs)
Responses: Re: Question on pgbench output  (David Kerr)
List: pgsql-performance

Tree view

Question on pgbench output  (David Kerr, )
 Re: Question on pgbench output  (Tom Lane, )
  Re: Question on pgbench output  (David Kerr, )
   Re: Question on pgbench output  (Tom Lane, )
 Re: Question on pgbench output  (Scott Marlowe, )
 Re: Question on pgbench output  (Greg Smith, )
  Re: Question on pgbench output  (Tom Lane, )
   Re: Question on pgbench output  (David Kerr, )
    Re: Question on pgbench output  (David Kerr, )
    Re: Question on pgbench output  (Simon Riggs, )
     Re: Question on pgbench output  (Tom Lane, )
      Re: Question on pgbench output  (David Kerr, )
       Re: Question on pgbench output  (Tom Lane, )
   Re: Question on pgbench output  (Greg Smith, )
    Re: Question on pgbench output  (David Kerr, )

Simon Riggs <> writes:
> On Fri, 2009-04-03 at 16:34 -0700, David Kerr wrote:
>> 400 concurrent users doesn't mean that they're pulling 1.5 megs /
>> second every second.

> There's a world of difference between 400 connected and 400 concurrent
> users. You've been testing 400 concurrent users, yet without measuring
> data transfer. The think time will bring the number of users right down
> again, but you really need to include the much higher than normal data
> transfer into your measurements and pgbench won't help there.

Actually pgbench can simulate think time perfectly well: use its \sleep
command in your script.  I think you can even set it up to randomize the
sleep time.

I agree that it seems David has been measuring a case far beyond what
his real problem is.

            regards, tom lane


pgsql-performance by date:

From: Lists
Date:
Subject: Best replication solution?
From: Lists
Date:
Subject: Re: Best replication solution?