Re: Question on pgbench output

From: David Kerr <dmk(at)mr-paradox(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Question on pgbench output
Date: 2009-04-03 21:18:21
Message-ID: 20090403211821.GB54342@mr-paradox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Apr 03, 2009 at 04:43:29PM -0400, Tom Lane wrote:
- > I'm not really sure how to evaulate the tps, I've read in this forum that
- > some folks are getting 2k tps so this wouldn't appear to be good to me.
-
- Well, you're running a custom transaction definition so comparing your
- number to anyone else's is 100% meaningless. All you know here is that
- your individual transactions are more expensive than the default pgbench
- transaction (which we could'a told you without testing...)

That makes sense. I guess I included it incase there was a community
defined sense of what a good TPS for a highly responsive web-app.
(like if you're getting 1000tps on your web app then your users are
happy)

But from the sounds of it, yeah, that would probably be difficult to
really measure.

- > (I wrote a script to average the total transaction time for every record
- > in the file)
- > avg_times.ksh pgbench_log.7205
- > Avg tx time seconds: 7
-
- That squares with your previous results: if you're completing 50
- transactions per sec then it takes about 8 seconds to do 400 of 'em.
- So any one of the clients ought to see about 8 second response time.
- I think that your test is probably valid.

Ok, great. thanks!

- > That's not too bad, it seems like with real hardware + actually tuning
- > the DB i might be able to meet my requirement.
-
- How much more "real" is the target hardware than what you have?
- You appear to need about a factor of 10 better disk throughput than
- you have, and that's not going to be too cheap. I suspect that the
- thing is going to be seek-limited, and seek rate is definitely the
- most expensive number to increase.

The hardware i'm using is a 5 or 6 year old POS IBM Blade. we haven't
specced the new hardware yet but I would say that it will be sigificantly
better.

- If the items you're pulling are static files, you should consider
- storing them as plain files and just using the DB as an index.
- Megabyte-sized fields aren't the cheapest things to push around.

I agree 100% and of course the memory allocation, etc from being able
to cache the items in httpd vs in the DB is a major consideration.

Thanks again.

Dave Kerr

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2009-04-03 21:43:13 Re: Question on pgbench output
Previous Message Tom Lane 2009-04-03 20:43:29 Re: Question on pgbench output