[
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.