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
