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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
