[
https://issues.apache.org/jira/browse/KUDU-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186897#comment-17186897
]
wangningito commented on KUDU-3133:
-----------------------------------
Recently we are trying to upgrade the java client from 1.6 to 1.10. It takes me
lots hours tracing the source the poor performance.
It take me hours to run git bisect and benchmarking .I find the slow
performance is first introduced in this commit.
[https://github.com/apache/kudu/commit/8ea955d7645ae9a1ef6a816b2f28b2661f2f87d2]
This commit introduced PREFERRED_CIPHER_SUITES as the setEnabledCipherSuites.
So the default cipher of tls is changed from '
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384' to
'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384'.
To my intuition, gcm is faster than cbc. However we can reach a conclusion
with these two threads
[https://stackoverflow.com/questions/25992131/slow-aes-gcm-encryption-and-decryption-with-java-8u20]
and
[https://stackoverflow.com/questions/29577804/java-server-tlsv1-1-fast-tlsv1-2-extremely-slow-90mbyte-sec-versus-4mbyte-sec]
, that jdk implemented gcm is much slower than cbc.
Thus I comment the line 527 in
[https://github.com/apache/kudu/commit/8ea955d7645ae9a1ef6a816b2f28b2661f2f87d2]
and rebuilt the jar. Everything works well as before.
[~granthenke] With above, I think maybe the affect versions can be set as 1.7
and 1.7+. And the commit changed the default behavior in jdk 8 and result in
poor performance.
Here is a simple solution which is quoted from above thread.
save this in file like java.security
jdk.tls.disabledAlgorithms=SSLv3,GCM
and start java with jdk argument
java -Djava.security.properties=/path/to/my/java.security ...
> Poor TLS cypher performance on Java 8
> -------------------------------------
>
> Key: KUDU-3133
> URL: https://issues.apache.org/jira/browse/KUDU-3133
> Project: Kudu
> Issue Type: Bug
> Components: perf, security
> Reporter: Grant Henke
> Priority: Major
>
> It was reported a while back that Kudu TLS doesn't perform well on Java 8 due
> to a potential GCM cypher bug or bad selection via `PREFERRED_CIPHER_SUITES`.
> It would be good to get to the bottom of this and fix it or document the
> recommendation to use Java 11.
> Here was the observed impact:
> {code}
> ./bin/ycsb run kudu -P workloads/workloadc -p operationcount=100000000
> -threads 64 -p kudu_num_clients=16 -s -p fieldlength=10000 -p
> kudu_table_num_replicas=1
> java 7u75 with master:
> 0205 11:18:48.647920 (+ 28us) server_negotiation.cc:581] Negotiated
> TLSv1 with cipher AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
> ~12k rows/sec
> java 8_141 with master:
> 0205 11:17:45.977107 (+ 31us) server_negotiation.cc:581] Negotiated
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
> Enc=AESGCM(256) Mac=AEAD
> 6k rows/sec
> java 8_141 with GCM-based codecs removed from Negotiator.java
> 0205 11:25:33.268689 (+ 40us) server_negotiation.cc:581] Negotiated
> TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA
> Enc=AES(256) Mac=SHA384
> ~6k rows/sec
> java 8_141 with only AES256-SHA remaining in Negotiator.java:
> "TLS_RSA_WITH_AES_256_CBC_SHA" )
> 0205 11:32:07.674860 (+ 44us) server_negotiation.cc:581] Negotiated
> TLSv1.2 with cipher AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
> ~9.5k rows/sec
> java 11 with master:
> 0205 11:17:01.416066 (+ 41us) server_negotiation.cc:581] Negotiated
> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
> Enc=AESGCM(256) Mac=AEAD
> ~19k rows/sec
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
