db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: 10.8.1 testing
Date Wed, 27 Apr 2011 16:22:22 GMT
Tiago Espinha <tiago@espinhas.net> writes:

> How exactly did you notice the performance change with DERBY-5068? I
> would like to be able to replicate this myself. Was it just during
> the test runs? Or do you have a concrete scenario where it's
> noticeable?

Hi Tiago,

I've only seen this in the nightly performance regression tests. (That's
the only place I've been looking for it so far...) The reported
throughput from the tests didn't change much, that's why it wasn't
noticed before, but the CPU per transaction seems to have increased on
the client side.

In all of these tests, the clients have lots of free CPU cycles, they're
spending much of their time waiting on a socket read call, so an
increase in CPU usage doesn't necessarily cause lower throughput.

We may be able to get these tests to show a difference in throughput if
we run the network server on the same machine as the clients. In that
case, less time would be spent waiting on network I/O, and the clients
would have to compete with the server process for the CPU cycles, so
increased CPU should mean that the system is able to process fewer
transactions per time unit.

One quick way to test it would be to start a network server on localhost
(with insane jars) and then run the test client with this command:

java org.apache.derbyTesting.perf.clients.Runner \
    -load sr_select -driver org.apache.derby.jdbc.ClientDriver \
    -url 'jdbc:derby://localhost/db;create=true' -threads 10 -init

We could try a couple times with 10.6.2.1 and 10.7.1.1 and see if they
report different results.

-- 
Knut Anders

Mime
View raw message