Steve,
Per your and Tom's recommendations, I significantly increased the
number of transactions used for testing. See my last post.
The database will have pretty heavy mixed use, i.e., both reads and
writes.
I performed 32 iterations per scenario this go-round.
I'll look into OSDB for further benchmarking. Thanks for the tip.
Since pgbench is part of the postgres distribution and I had it at hand
and it seems to be somewhat widely referenced, I figured I go ahead and
post preliminary results from it.
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
On Apr 15, 2005, at 4:24 PM, Steve Poe wrote:
> Tom,
>
> People's opinions on pgbench may vary, so take what I say with a grain
> of salt. Here are my thoughts:
>
> 1) Test with no less than 200 transactions per client. I've heard with
> less than this, your results will vary too much with the direction of
> the wind blowing. A high enough value will help rule out some "noise"
> factor. If I am wrong, please let me know.
>
>
> 2) How is the database going to be used? What percentage will be
> read/write if you had to guess? Pgbench is like a TPC-B with will help
> guage the potential throughput of your tps. However, it may not stress
> the server enough to help you make key performance changes. However,
> benchmarks are like statistics...full of lies <g>.
>
> 3) Run not just a couple pgbench runs, but *many* (I do between 20-40
> runs) so you can rule out noise and guage improvement on median
> results.
>
> 4) Find something that you test OLTP-type transactions. I used OSDB
> since it is simple to implement and use. Although OSDL's OLTP testing
> will closer to reality.
>
> Steve Poe
