[EMAIL PROTECTED] (Dag H. Wanvik) writes: > Knut Anders Hatlen <[EMAIL PROTECTED]> 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
Index: java/engine/org/apache/derby/impl/sql/execute/GenericExecutionFactory.java
===================================================================
--- java/engine/org/apache/derby/impl/sql/execute/GenericExecutionFactory.java (revision 674436)
+++ java/engine/org/apache/derby/impl/sql/execute/GenericExecutionFactory.java (working copy)
@@ -354,10 +354,12 @@
return new IndexValueRow(valueRow);
}
+ public static ExecutionFactory DEFAULT_INSTANCE;
//
// class interface
//
public GenericExecutionFactory() {
+ DEFAULT_INSTANCE = this;
}
//
Index: java/engine/org/apache/derby/impl/store/access/RAMAccessManager.java
===================================================================
--- java/engine/org/apache/derby/impl/store/access/RAMAccessManager.java (revision 674436)
+++ java/engine/org/apache/derby/impl/store/access/RAMAccessManager.java (working copy)
@@ -153,8 +153,10 @@
**************************************************************************
*/
+ public static RAMAccessManager DEFAULT_INSTANCE;
public RAMAccessManager()
{
+ DEFAULT_INSTANCE = this;
// Intialize the hash tables that hold the access methods that
// this access manager knows about.
implhash = new Hashtable();
SimpleSelect.java
Description: Binary data
