On Tue, 22 May 2007, Gregory Stark wrote:
> However as mentioned a while back in practice it doesn't work quite right and
> you should expect to get 1/2 the expected performance. So even with 10 clients
> you should expect to see 5*120 tps on a 7200 rpm drive and 5*250 tps on a
> 15kprm drive.
I would agree that's the approximate size of the upper-bound. There are
so many factors that go into the effectiveness of commit_delay that I
wouldn't word it so strongly as to say you can "expect" that much benefit.
The exact delay amount (which can be hard to set if your client load
varies greatly), size of the transactions, balance of seek-bound reads vs.
memory based ones in the transactions, serialization in the transaction
stream, and so many other things can slow the effective benefit.
Also, there are generally other performance issues in the types of systems
you would think would get the most benefit from this parameter that end up
slowing things down anyway. I've been seeing a best case of closer to
2*single tps rather than 5* on my single-drive systems with no write
caching, but I'll admit I haven't done an exhausting look at it yet (too
busy with the real systems that have good controllers). One of these
days...
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
