On Fri, 19 Nov 2021 at 02:51, Joseph Lynch<joe.e.ly...@gmail.com> wrote:
On Thu, Nov 18, 2021 at 7:23 PM Kokoori, Shylaja <
shylaja.koko...@intel.com>
wrote:
To address Joey's concern, the OpenJDK JVM and its derivatives
optimize
Java crypto based on the underlying HW capabilities. For example, if
the
underlying HW supports AES-NI, JVM intrinsics will use those for
crypto
operations. Likewise, the new vector AES available on the latest Intel
platform is utilized by the JVM while running on that platform to make
crypto operations faster.
Which JDK version were you running? We have had a number of issues with
the
JVM being 2-10x slower than native crypto on Java 8 (especially MD5,
SHA1,
and AES-GCM) and to a lesser extent Java 11 (usually ~2x slower). Again
I
think we could get the JVM crypto penalty down to ~2x native if we
linked
in e.g. ACCP by default [1, 2] but even the very best Java crypto I've
seen
(fully utilizing hardware instructions) is still ~2x slower than native
code. The operating system has a number of advantages here in that they
don't pay JVM allocation costs or the JNI barrier (in the case of ACCP)
and
the kernel also takes advantage of hardware instructions.
From our internal experiments, we see single digit % regression when
transparent data encryption is enabled.
Which workloads are you testing and how are you measuring the
regression? I
suspect that compaction, repair (validation compaction), streaming, and
quorum reads are probably much slower (probably ~10x slower for the
throughput bound operations and ~2x slower on the read path). As
compaction/repair/streaming usually take up between 10-20% of available
CPU
cycles making them 2x slower might show up as <10% overall utilization
increase when you've really regressed 100% or more on key metrics
(compaction throughput, streaming throughput, memory allocation rate,
etc
...). For example, if compaction was able to achieve 2 MiBps of
throughput
before encryption and it was only able to achieve 1MiBps of throughput
afterwards, that would be a huge real world impact to operators as
compactions now take twice as long.
I think a CEP or details on the ticket that indicate the performance
tests
and workloads that will be run might be wise? Perhaps something like
"encryption creates no more than a 1% regression of: compaction
throughput
(MiBps), streaming throughput (MiBps), repair validation throughput
(duration of full repair on the entire cluster), read throughput at 10ms
p99 tail at quorum consistency (QPS handled while not exceeding P99 SLO
of
10ms), etc ... while a sustained load is applied to a multi-node
cluster"?
Are you for real here?Nobody will ever guarantee you these %1 numbers
... come on. I think we are
super paranoid about performance when we are not paranoid enough about
security. This is a two way street.
People are willing to give up on performance if security is a must.
You do not need to use it if you do not want to,
it is not like we are going to turn it on and you have to stick with
that. Are you just saying that we are going to
protect people from using some security features because their db
might be slow? What if they just dont care?
Even a microbenchmark that just sees how long it takes to encrypt and
decrypt a 500MiB dataset using the proposed JVM implementation versus
encrypting it with a native implementation might be enough to
confirm/deny.
For example, keypipe (C, [3]) achieves around 2.8 GiBps symmetric of
AES-GCM and age (golang, ChaCha20-Poly1305, [4]) achieves about 1.6
GiBps
encryption and 1.0 GiBps decryption; from my past experiences with Java
crypto is it would achieve maybe 200 MiBps of _non-authenticated_ AES.
Cheers,
-Joey
[1]https://issues.apache.org/jira/browse/CASSANDRA-15294
[2]https://github.com/corretto/amazon-corretto-crypto-provider
[3]https://github.com/FiloSottile/age
[4]https://github.com/hashbrowncipher/keypipe#encryption
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail:dev-h...@cassandra.apache.org