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: simpler api to the Derby store
Date Thu, 17 Jul 2008 10:11:36 GMT
Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> Knut Anders Hatlen <Knut.Hatlen@Sun.COM> writes:
>
>> Not an answer to your question, but I performed a small experiment to
>> get a feel of how large the overhead imposed by the SQL and JDBC layers
>> was for these simple queries. I used the single-record select test in
>> org.apache.derbyTesting.perf.clients.Runner, which just performs primary
>> key lookups and fetches about 100 bytes of data. When I accessed the
>> same table and index directly through the store API (using same
>> isolation level, holdability etc), I got about 15% more accesses per
>> unit of time than when I accessed them through JDBC.
>
> Interesting experiment. I am not too surprised by the 15% overhead, I
> think many people think JDBC using prepared statements is slower than
> it actually is in embedded mode, since for many it conjures up images
> of networking latency, extra serializing and deserializing. So in some
> sense Derby embedded may have an "image problem" since we rely on JDBC
> solely.
>
> In any case, it might be educational for some of us when we look into
> this question if you would be willing to share the experiment code
> with the community?  Then maybe others can get a jump start to do more
> experiments?

Sure. I made a couple of small changes to the Derby code in order to
make it easier to get a reference to the ExecutionFactory and the
AccessFactory. The attached factories.diff contains those changes.

The code for the test itself is contained in SimpleSelect.java (not a
very descriptive name, since I would rather say that the equivalent JDBC
code is simpler). To use it, first create a database and tables with the
performance tests in derbyTesting.jar:

  java -cp derby.jar:derbyTesting.jar \
    org.apache.derbyTesting.perf.clients.Runner -load sr_select -init

The test itself takes three command line parameters: the number of
threads, how many seconds the warmup phase should last, and how long the
steady-state during which transactions are counted should last. It'll
query the system tables to find out which conglomerates are used for the
index and the heap for the table created in the first step. To run the
test with one thread for one minute, with 30 sec warmup, and a page
cache large enough to hold the entire table and index:

  java -Dderby.storage.pageCacheSize=12500 SimpleSelect 1 30 60

-- 
Knut Anders

Mime
View raw message