db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Performance regressions
Date Tue, 21 Feb 2006 21:57:24 GMT
For multi user tests I would not worry about batching the
tests as much.  It would be better if we can demonstrate
that as more users are added throughput increases.  If we
are using 6% of the cpu I could see it taking more than 17
threads running unblocks to drive the group commit log fast
enough to use up all the cpu.

Olav.Sandstaa wrote:
> Mike Matrigali <mikem_app@sbcglobal.net> wrote:
> 
>>ok, I was hoping that for single user testing it wouldn't
>>be a big change.  The single user commit per update is
>>a problem when comparing derby to other db's which don't
>>do real transaction guarantees.  It would be great if
>>someone reading the derby web site would pick the 1000
>>row per commit single user case to look at first.
> 
> 
> I agree that for the single user testing it should not be a big change. I
> might give it a try and see what results I get.
>  
> 
>>I just looked at the insert case, and on the following
>>page it looks to me like the single user case is taking
>>about 6% user time and 2% system time.  Am I reading
>>the %cpu graph correctly? From the description
>>I think this is a 2 processor machine.  With 2 processors
>>will it be possible to register 200% of cpu or just 100%
>>of cpu (I have seen both possibilities on multiprocessor
>>machines depending on the tool).
> 
> 
> You are right about the interpretation of the CPU graphs, the second CPU graph
> shows the amount of CPU that the java process (client code and Derby embedded)
> uses in user and system time. It is a 2 CPU machine, and in CPU scale goes to
> 100%.
> 
> What surprices me a bit when looking at the CPU graph is that in the single
> user case even with the write cache on the disks enabled we are only able
> utilize about 6-7 percent of the CPU. I will look into it, but I guess it is
> the disk where the log is written that limits the throughput.
> 
> ..olav
> 
> 
> 
>>Olav Sandstaa wrote:
>>
>>>Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>>>
>>>
>>>>Thanks for the info, anything is better than nothing.
>>>>Any chance to measure something like 1000 records per commit.
>>>>With one record per commit for the update operations you are
>>>>not really measuring the work to do the operation just the
>>>>overhead of commit -- at least for the single user case --
>>>>assuming your machine is set up to let derby do real disk
>>>>syncs (no write cache enabled).
>>>
>>>
>>>The write cache on the disks are enabled in order make this test CPU
>>>bound also for insert, update and delete load instead of disk bound. I
>>>agree that only having one insert/update/delete operation per
>>>transaction/commit we include a lot of overhead for the commit. The
>>>intention is not to measure throughput, but to identify regressions
>>>and even if the commit takes 50 percent (just guessing) of the CPU
>>>cost/work of doing an update transaction it should still be possible to
>>>identify if there are changes in the update operation itself that
>>>influence on the CPU usage/throughput.
>>>
>>>Unfortunately I will have to make major changes to the test client if
>>>it should do 1000 updates per commit. All clients work on the same
>>>table and perform the operation on a random record. With multiple
>>>updates per transaction it would lead to a lot of deadlocks. I think
>>>it would be better to write a new load client than to try to tweek the
>>>one I run right now.
>>>
>>>I am also running some tests where the write cache on the disks are
>>>disabled (as it should be), but I have not included the results on
>>>the web page yet (mostly due to much higher variation in the test
>>>results).
>>>
>>>..olav
>>>
>>>
>>>
>>
> 
> 


Mime
View raw message