cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Tolbert (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-10735) Support netty openssl (netty-tcnative) for client encryption
Date Wed, 25 Nov 2015 01:51:11 GMT

    [ 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:50 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_small.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!

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, nettysslbench_small.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)

Mime
View raw message