Jonas Ahlinder wrote:
The benchmark client is single-threaded atm.
To run it multi-threaded some sort of locking will most likely have ot me
implemented ( which will be done as soon as we can confirmt he performance is
ok ).
I have tried running more threads, and it does seem to give better performance,
but the current state of the client doesnt really allow for reliable
testresults.
With autocommit on, and with the disk running 100% usage ( and quite a bit of
wait queue at least on Linux ) do you think multiple threads will really help ?
And CPU ( 4 cores ) seem to run about 50% wait and 50% idle, which seems rather
wierd to me, but i guess its mostly waiting for IO.
Which disk is running at 100% usage? The data disk or the log disk?
If it is the log disk that is saturated, having multiple threads may
help throughput because then it will be possible to commit multiple
transactions per disk write.
--
Øystein
________________________________________
From: Bryan Pendleton [EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 5:43 PM
To: Derby Discussion
Subject: Re: performance issue
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm sata disks I get over 900 tps, while on a server (
running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
Is your benchmark client multi-threaded? Or single-threaded?
During the run(s) are your machine(s) CPU-bound? Or disk-bound?
thanks,
bryan
