[
https://issues.apache.org/jira/browse/DERBY-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150455#comment-13150455
]
Knut Anders Hatlen commented on DERBY-5503:
-------------------------------------------
I repeated Rick's experiment, only that I used the single-record
select client (sr_select) instead of single-record update (sr_update).
With that test client, I see much bigger differences, presumably
because the update client spends most of its time waiting for the log
to be flushed to disk on commit.
Here's what I see (average of three runs with each configuration):
No encryption:
- 1 thread: 25495 tx/s
- 8 threads: 42940 tx/s
- 16 threads: 41488 tx/s
Default encryption:
- 1 thread: 4007 tx/s (-84%)
- 8 threads: 3041 tx/s (-93%)
- 16 threads: 3086 tx/s (-93%)
AES 256-bit encryption:
- 1 thread: 8546 tx/s (-66%)
- 8 threads: 6766 tx/s (-84%)
- 16 threads: 6767 tx/s (-84%)
I ran the experiments with Java 7u1 on a Solaris 11 box with 8 cores.
> Measure the performance degradation incurred by encrypting Derby databases
> --------------------------------------------------------------------------
>
> Key: DERBY-5503
> URL: https://issues.apache.org/jira/browse/DERBY-5503
> Project: Derby
> Issue Type: Task
> Components: Store
> Affects Versions: 10.9.0.0
> Reporter: Rick Hillegas
>
> It would be good to measure the performance degradation incurred by Derby's
> encryption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
