db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Performance regression after check-in on DERBY 2537 (SVN 531971)
Date Tue, 08 May 2007 19:41:36 GMT
Olav Sandstaa <Olav.Sandstaa@Sun.COM> writes:

> Attached is a slightly modified version of the test client found in
> DERBY-1961. The main change I have done is to add a secondary index to
> it that is used for the queries. Running this with two clients on a
> dual CPU machine running Linux and using IBM JVM 1.5 I see a drop in
> throughput of about 6 percent (down from 16656 tps to 15706 tps - 
> average of five runs).

Thanks for the test client, Olav.

I ran the test on my single-CPU Athlon 64 running OpenSolaris and got
almost the same results as you. When moving from revision 531970 to
revision 531971, the throughput dropped by between 6% and 22%. I used
Sun Java 1.6 (server VM) and derby.storage.pageCacheSize=12500 for the
tests, and 1 to 20 concurrent clients.

More interestingly, I applied the derby827_update920.txt patch attached
to DERBY-827 and reran the tests. With that patch applied, there was no
difference between the two revisions as far as I could see. The results
from the test runs are attached as select.png.

I'm just guessing here, but could the DERBY-2537 check-in have pushed
the amount of object allocations over some threshold that made the gc
cost much higher, whereas the DERBY-827 patch reduced the total amount
of allocations by so much that gc is able to cope with the small
increase from DERBY-2537?

-- 
Knut Anders

Mime
View raw message