The actual performance data from the regression test that made me
suspect there had been a regression are available here:
http://home.online.no/~olmsan/derby/perf/select_sec_index_30d.html
These are produced using the same test client as in the graphs I sent
out earlier. In addition to include the throughput numbers, CPU numbers
are presented that also indicate increased CPU usage.
These tests are run with JDK6 on Solaris 10.
Olav
Olav Sandstaa wrote:
The two last days I have seen a performance regression in some of the
performance tests I run. For some of the tests the reduction in
throughput is about 15 percent. It seems like the regression is
introduced by the latest check-in on DERBY-2537, svn 531971.
I have attached a graph showing the throughput I get when running
single-record select operation on a table. The queries use a secondary
index for finding the record to select. The test has been run with 1
to 20 concurrent client against embedded Derby. I have run the test
with and without SVN 531971. As the graph shows, the performance
reduction is between 12 and 15 percent for all runs.
The schema looks like this:
CREATE TABLE t1 id INTEGER sec_id INTEGER data CHARACTER(100)
PRIMARY KEY(id))
CREATE INDEX nonprimary_index ON t1 (sec_id)
Each query do the select on the secondary index and retrieves the data
field (a CHARACTER(100) field).
I would expect some of the changes done in the patch to have some
influence on the performance, but not in the order of 10-15 percent.
The tests are run on a 2 CPU Opteron server running Solaris 10 and JDK 6.
Olav
------------------------------------------------------------------------
