[
https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649982#comment-14649982
]
Jason Brown commented on CASSANDRA-9945:
----------------------------------------
wrt to the thread local, it looks like {{Cipher#init}} is the biggest hog,
however, there is still much to be gained by not creating a new Cipher instance
each time. Here's [my
variation|https://gist.github.com/jasobrown/99daa06776b926bdf987] on [~snazy]'s
benchmark class; this reflects a little closer the actual use pattern in my
patch. The biggest difference is I force the Cipher to {{init}} on every call,
for both thread local and non-thread local.
The results are as follows:
{code}
snazy:
Benchmark (cipher) Mode Cnt Score
Error Units
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding thrpt 5 0.636 ±
0.031 ops/us
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding thrpt 5 594.063 ±
58.416 ops/us
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding avgt 5 4.873 ±
0.211 us/op
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding avgt 5 0.005 ±
0.001 us/op
jasobrown:
Benchmark (cipher) Mode Cnt Score Error
Units
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding thrpt 5 0.402 ± 0.133
ops/us
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding thrpt 5 27.989 ± 7.341
ops/us
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding avgt 5 8.527 ± 1.828
us/op
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding avgt 5 0.093 ± 0.001
us/op
{code}
Thus, I think there's still benefit to using the thread local, to avoid the
{{Cipher#getInstance}} call, and if we check the cipher, alg, iv, and so on,
match the input params (when we fish out the Cipher instance form the thread
local), then we can avoid the {{Cipher#init}} call, as well.
> Add transparent data encryption core classes
> --------------------------------------------
>
> Key: CASSANDRA-9945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9945
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jason Brown
> Assignee: Jason Brown
> Labels: encryption
> Fix For: 3.0 beta 1
>
>
> This patch will add the core infrastructure classes necessary for transparent
> data encryption (file-level encryption), as required for CASSANDRA-6018 and
> CASSANDRA-9633. The phrase "transparent data encryption", while not the most
> aesthetically pleasing, seems to be used throughout the database industry
> (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption,
> so we'll go with that, as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
