[
https://issues.apache.org/jira/browse/KNOX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645487#comment-16645487
]
Kevin Risden edited comment on KNOX-1221 at 10/10/18 8:53 PM:
--------------------------------------------------------------
h2. TLS/SSL vs Non TLS/SSL Performance Differences Explanation
The biggest difference identified in both the read and write performance was
TLS/SSL vs Non TLS/SSL. After investigation, I didn't find any Knox bottlenecks
for the read side. The difference between TLS/SSL and Non TLS/SSL can be solely
attributed to the JDK and the implementation of TLS/SSL.
* [https://nbsoftsolutions.com/blog/the-cost-of-tls-in-java-and-solutions]
* [https://nbsoftsolutions.com/blog/dropwizard-1-3-upcoming-tls-improvements]
* [https://webtide.com/conscrypting-native-ssl-for-jetty/]
I was able to test Conscrypt with Knox and able to get TLS/SSL performance on
par with Non TLS/SSL (within .3 s). Conscrypt replaces the JDK implementation
of a security provider and instead uses a wrapped BoringSSL implementation.
This avoids the slowness of TLS/SSL encryption.
One suggestion from the mailing list was to example TLS/SSL ciphers. I found
information online that states that GCM ciphers (default in JDK 8) are slow due
to the JDK implementation.
* [https://www.wowza.com/docs/how-to-improve-ssl-performance-with-java-8]
*
[https://stackoverflow.com/questions/25992131/slow-aes-gcm-encryption-and-decryption-with-java-8u20]
I tested ignoring the GCM ciphers by adding GCM to the disabledAlgorithms list
for java.security. The results for the read were:
* Native WebHDFS - 252MB/s in 3.8s
* Non TLS/SSL Knox - 264MB/s in 3.6s
* TLS/SSL Knox no GCM - 125MB/s in 8.7s
* TLS/SSL Knox - 54.3MB/s in 20s
This is a little more than a 2x speedup. There is also information in the links
above that there should be more performance improvements with JDK 9+. Even with
GCM algorithms excluded, the JDK imposes almost a 2x performance penalty for
using TLS/SSL. As described above it is possible to use a different security
provider like Conscrypt to get the best performance.
was (Author: risdenk):
h2. TLS/SSL vs Non TLS/SSL Performance Differences Explanation
The biggest difference identified in both the read and write performance was
TLS/SSL vs Non TLS/SSL. After investigation, I didn't find any Knox bottlenecks
for the read side. The difference between TLS/SSL and Non TLS/SSL can be solely
attributed to the JDK and the implementation of TLS/SSL.
* [https://nbsoftsolutions.com/blog/the-cost-of-tls-in-java-and-solutions]
* [https://nbsoftsolutions.com/blog/dropwizard-1-3-upcoming-tls-improvements]
* [https://webtide.com/conscrypting-native-ssl-for-jetty/]
I was able to test Conscrypt with Knox and able to get TLS/SSL performance on
par with Non TLS/SSL (within .3 s). Conscrypt replaces the JDK implementation
of a security provider and instead uses a wrapped BoringSSL implementation.
This avoids the slowness of TLS/SSL encryption.
One suggestion from the mailing list was to example TLS/SSL ciphers. I found
information online that states that GCM ciphers (default in JDK 8) are slow due
to the JDK implementation.
* [https://www.wowza.com/docs/how-to-improve-ssl-performance-with-java-8]
*
[https://stackoverflow.com/questions/25992131/slow-aes-gcm-encryption-and-decryption-with-java-8u20]
I tested ignoring the GCM ciphers by adding GCM to the disabledAlgorithms list
for java.security. The results for the read were:
* Native WebHDFS - 252MB/s in 3.8s
* Non TLS/SSL Knox - 264MB/s in 3.6s
* TLS/SSL Knox no GCM - 125MB/s in 8.7s
* TLS/SSL Knox - 54.3MB/s in 20s
This is a little more than a 2x speedup. There is also information in the links
above that there should be more performance improvements with JDK 9+.
> WebHDFS read/write performance limitations
> ------------------------------------------
>
> Key: KNOX-1221
> URL: https://issues.apache.org/jira/browse/KNOX-1221
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.9.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 1.0.0,
> 1.1.0
> Environment: Knox 1.0.0
> RHEL 6.9
> JDK 1.8.0_60
> Launch string:
> /usr/bin/java -Djava.library.path=/opt/knox-1.0.0/ext/native -Xms2g -Xmx8g
> -Dcom.sun.management.jmxremote
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.port=9000 -jar /opt/knox-1.0.0/bin/gateway.jar
> Reporter: Georgy
> Assignee: Kevin Risden
> Priority: Major
> Fix For: 1.2.0
>
> Attachments: gateway-site.xml, rtk.xml
>
>
> If I use direct connection to WebHDFS from one node I have speed nearly
> several gigabites/sec when download or upload large files. But if I use knox
> I have ulpload/download speed only 100mbit/sec from the same node. Found that
> knox limits speed for one https session. As a workaround I upload large files
> through knox in parallel but it is not a good way.
> Couldn't find any configuration params that can control such behaviour. Is it
> a code limitation?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
