[
https://issues.apache.org/jira/browse/CASSANDRA-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025970#comment-15025970
]
Andy Tolbert edited comment on CASSANDRA-10735 at 11/25/15 1:47 AM:
--------------------------------------------------------------------
I made an attempt at implementing this just to get an idea of what kind of
performance improvement would be seen. My changes are on a [personal
branch|https://github.com/tolbertam/cassandra/tree/CASSANDRA-10735] in github.
Summary of changes:
* Update from netty 4.0.23 to 4.0.33, primarily for SslContextBuilder and I
think some API calls may be missing at 4.0.23 (need to confirm).
* Add support for using netty openssl. This requires platform-specific
netty-tcnative jar in classpath (did not put in build.xml), openssl, and
libapr1.
* Netty's SslContext is used for both openssl and jdk ssl.
* New config options under client_encryption_options:
** provider (default jdk): What ssl provider to use (openssl|jdk)
** key_cert_chain: certificate to use for server.
** key: private key file for cert.
** key_password (default: null (unprotected): password for private key file if
encrypted.
** trust_cert_chain: certificate chain file for trust (used only if
use_client_auth is true).
* I also have some changes to use netty ssl with the java driver in
cassandra-stress, but these aren't included (but will add them).
stress output including graph data from [CASSANDRA-7918]: [^nettyssl-bench.tgz]
The throughput improvement is very apparent when using netty openssl in both C*
and the java driver, but not so much if one of the two is not using it as
exhibited below:
Legend (highest write throughput to worst):
||Color||Client Config||Server Config||op/s rate||+/- ops nossl||total gc mb||
||Purple|None|None|109047|0%|61097|
||Blue|OpenSSL|OpenSSL|76849|-29.5%|75400|
||Green|OpenSSL|JDK SSL|26331|-75.9%|146380|
||Orange|JDK SSL|OpenSSL|25450|-76.7%|112929|
||Red|JDK SSL|JDK SSL|18577|-82.3%|152548|
!nettysslbench.png!
See html file in [^nettyssl-bench.tgz] for more graphical data (doesn't work in
chrome for some reason, but works for me in safari).
I believe the variance between no ssl and using netty openssl would be less
pronounced if system cpu was not saturated during the test.
Hardware configuration (both client and server):
* 2 x Xeon 12 cores CPU
* 128 GB RAM
* 2 x Samsung 1 TB SSD (850 EVO)
* 2 x Gigabit Ethernet
was (Author: andrew.tolbert):
I made an attempt at implementing this just to get an idea of what kind of
performance improvement would be seen. My changes are on a [personal
branch|https://github.com/tolbertam/cassandra/tree/CASSANDRA-10735] in github.
Summary of changes:
* Update from netty 4.0.23 to 4.0.33, primarily for SslContextBuilder and I
think some API calls may be missing at 4.0.23 (need to confirm).
* Add support for using netty openssl. This requires platform-specific
netty-tcnative jar in classpath (did not put in build.xml), openssl, and
libapr1.
* Netty's SslContext is used for both openssl and jdk ssl.
* New config options under client_encryption_options:
** provider (default jdk): What ssl provider to use (openssl|jdk)
** key_cert_chain: certificate to use for server.
** key: private key file for cert.
** key_password (default: null (unprotected): password for private key file if
encrypted.
** trust_cert_chain: certificate chain file for trust (used only if
use_client_auth is true).
* I also have some changes to use netty ssl with the java driver in
cassandra-stress, but these aren't included (but will add them).
stress output including graph data from [CASSANDRA-7918]: [^nettyssl-bench.tgz]
The throughput improvement is very apparent when using netty openssl in both C*
and the java driver, but not so much if one of the two is not using it as
exhibited below:
Legend (highest write throughput to worst):
||Color||Client Config||Server Config||op/s rate||+/- ops nossl||total gc mb||
||Purple|None|None|109047|0%|61097|
||Blue|OpenSSL|OpenSSL|76849|-29.5%|75400|
||Green|OpenSSL|JDK SSL|26331|-75.9%|146380|
||Orange|JDK SSL|OpenSSL|25450|-76.7%|112929|
||Red|JDK SSL|JDK SSL|18577|-82.3%|152548|
!nettysslbench.png|thumbnail!
See html file in [^nettyssl-bench.tgz] for more graphical data (doesn't work in
chrome for some reason, but works for me in safari).
I believe the variance between no ssl and using netty openssl would be less
pronounced if system cpu was not saturated during the test.
Hardware configuration (both client and server):
* 2 x Xeon 12 cores CPU
* 128 GB RAM
* 2 x Samsung 1 TB SSD (850 EVO)
* 2 x Gigabit Ethernet
> Support netty openssl (netty-tcnative) for client encryption
> ------------------------------------------------------------
>
> Key: CASSANDRA-10735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10735
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Andy Tolbert
> Fix For: 3.x
>
> Attachments: nettyssl-bench.tgz, nettysslbench.png
>
>
> The java-driver recently added support for using netty openssl via
> [netty-tcnative|http://netty.io/wiki/forked-tomcat-native.html] in
> [JAVA-841|https://datastax-oss.atlassian.net/browse/JAVA-841], this shows a
> very measured improvement (numbers incoming on that ticket). It seems
> likely that this can offer improvement if implemented C* side as well.
> Since netty-tcnative has platform specific requirements, this should not be
> made the default, but rather be an option that one can use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
