Re: db block size, too big wasting buffer?

In article <b3cb12d6.0206250904.780208d6_at_posting.google.com>, you said (and I quote):
>
> With so much time wasted debating, one could do a very thorough
> benchmark convincing everybody. But nobody has done so. (Me included!)
>

Well, if I may throw in my 0.02 worth on benchmarking:

To benchmark accurately we need repeatable cases.

With a batch system, it's dead easy. All you need is a batch run that you can schedule and repeat ad infinitum, with/without other concurrent runs.

With an online system (be it OLTP or DSS), it is extremely difficult to do. We're talking pseudo-random transaction arrival rates, with extremely variable service queue length. I'm afraid there is a LOT more to it than just R=S+W... That formula is an over-simplification (perfectly justified in its context).

Back in the days when I was running benchmarks for Sperry and Prime we had dedicated centres, with systems that would generate load, connected via discrete terminal lines to the systems under test. We spent as much or more time preparing the workload to be pumped through the transaction generators as we spent tuning the target systems. It was that complex.

Nowadays, there are tools that can help in this area. But I still have to see one benchmark setup done by anyone other than a BIG company that actually pays as much attention to simulating a realistic load as it does to measure results.

It is COMPLETELY USELESS to accurately measure an unrealistic load and extrapolate real life behaviour from it.

The anecdotal stories often mentioned here of people laboriously measuring the wrong wait time in their I/O subsystems are not a joke. In most "benchmarks" I've seen of late, it is unfortunately the case.

So, proceed with caution when benchmarking user interaction. Or do a batch benchmark and extrapolate queue service times from that constant load. Which is perfectly valid if done with care.

As in anything: YMMV, IMHO, etc.

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam