[
https://issues.apache.org/jira/browse/DERBY-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151423#comment-13151423
]
Mike Matrigali commented on DERBY-5503:
---------------------------------------
I only skimmed the links you provided, but enough to see that it seems like
there is a lot a varibility based on OS and filesystem.
>From your numbers I am thinking that on the read only test your setup loads
>the unix cache with decrypted blocks and then the tests basically never have
to do any decrypt on the subsequent readonly test runs. There may be system
specific ways to clear unix cache but only way I can think that
is completely safe is to do setup/creation of a large table, shutdown machine,
do one run on the table. That will guarantee read from disk and decryption
happening.
I don't have any explanation for the update encrypted filesystem. Would be
interesting to see if system is waiting more in this case or if it is really
spining the cpu doing encryption.
On a side note, scanning through the documentation it seemed like there were a
lot of options in the encrypted filesystems to turn sync write requests into
async write requests without the application knowing. This is a recipe for
corrupted derby databases on system crashes.
> 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
