db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <ti...@espinhas.net>
Subject Re: 10.8.1 testing
Date Wed, 27 Apr 2011 21:22:07 GMT
Ok, I will try this myself tomorrow.

Off the top of my head, if I recall correctly, before the UTF8 CCSID,
conversions were being done byte by byte as each character was always
guaranteed to be 1 byte at the most. If memory serves well, this was
actually just a cast into char, which I would expect to be fairly
inexpensive in terms of CPU.

With the UTF8 CCSID, we rely on the getBytes() (again, off the top of my
head) to actually convert Strings to and from UTF8. I'm guessing this has
the potential to cause some slowdown. If that's the case though, then the
scenario is even darker as it will in fact affect both client AND server.


On Wed, Apr 27, 2011 at 6:22 PM, Knut Anders Hatlen

> 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 and and see if they
> report different results.
> --
> Knut Anders

View raw message