Olav Sandstaa <[EMAIL PROTECTED]> 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
<<attachment: select.png>>
