You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jason Brown (JIRA)" <ji...@apache.org> on 2015/08/01 01:15:05 UTC
[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data
encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649982#comment-14649982 ]
Jason Brown edited comment on CASSANDRA-9945 at 7/31/15 11:14 PM:
------------------------------------------------------------------
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 (run on my laptop, in a VM):
{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.
was (Author: jasobrown):
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)