Re: Question on pgbench output

Поиск
Список
Период
Сортировка
От David Kerr
Тема Re: Question on pgbench output
Дата
Msg-id 20090403211821.GB54342@mr-paradox.net
обсуждение исходный текст
Ответ на Re: Question on pgbench output  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Question on pgbench output  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Question on pgbench output
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Question on pgbench output