[ 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 2:03 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 (313.68% increase in op/s for write) when using netty openssl in both C* and the java driver, but not so much if one of the two. The total gc'd mb is 50.58% less with openssl vs. jdk ssl. Legend (highest write throughput to worst): ||Color||Client Config||Server Config||op/s rate||% op/s diff existing SSL||total gc mb|| ||Purple|None|None|109047|--|61097| ||Blue|OpenSSL|OpenSSL|76849|+313.68%|75400| ||Green|OpenSSL|JDK SSL|26331|+41.7%|146380| ||Orange|JDK SSL|OpenSSL|25450|+37.0%|112929| ||Red|JDK SSL|JDK SSL|18577|0%|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_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 > 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)