db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3313) JDBC client driver statement cache
Date Fri, 27 Jun 2008 16:06:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kristian Waagan updated DERBY-3313:
-----------------------------------

    Attachment: bank_transaction_stmtcache_16c.png

'bank_transaction_stmtcache_16c.png' shows a graph for the performance of Derby running the
bank transaction performance client (see DERBY-3619) in three different configurations;
 a) Reuse of a single prepared statement for each query (original client code)
 b) Reprepare the statement every time with JDBC statement caching enabled
 c) Reprepare the statement every time with JDBC statement caching disabled

I modified the original performance client to achieve b and c.
The Derby network server was started with a page cache size of 10 000 and a max heap of 512
M, and the JDBC statement cache size was set to 15.
The client was invoked with the following arguments:
-driver org.apache.derby.jdbc.ClientDriver -url "jdbc:derby://myHost/tpcbDB;create=true" -load
bank_tx -threads 16 -load_opts "branches=16,accountsPerBranch=6250" [-init]

As the graph shows, the performance hit from repreparing statements with the JDBC client side
statement cache is almost negligible with this load profile. The extra work is performed on
the client, and in this case there was plenty of free CPU resourced on the client machine.
The fact that there are many clients makes the difference even smaller.

I'm also running with only one client, and the results seem to suggest a small performance
overhead for the JDBC statement cache. This is to be expected, as more work has to be done
than when reusing a single prepared statement. I'll post the results later when the run is
finished.

If I get some free cycles, I might run a read-only test too.

> JDBC client driver statement cache
> ----------------------------------
>
>                 Key: DERBY-3313
>                 URL: https://issues.apache.org/jira/browse/DERBY-3313
>             Project: Derby
>          Issue Type: New Feature
>          Components: JDBC, Network Client
>    Affects Versions: 10.4.1.3
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>             Fix For: 10.4.1.3
>
>         Attachments: bank_transaction_stmtcache_16c.png, derby-3313-1a-early_prototype.diff,
derby-3313-1a-early_prototype.stat, JDBCClientStatementCacheOverview.txt, JDBCClientStatementCacheOverview.txt
>
>
> A statement cache in the JDBC client driver will help increase performance in certain
scenarios, for instance some multi-tier systems using connection pooling.
> Please consult the comments and documents attached to this issue for more information.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message