-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS performance degradation when using Java 11 #856
Comments
Can you paste outputs from something like async profiler? (https://github.com/jvm-profiling-tools/async-profiler) This seems to be more of a problem with AdoptOpenJDK perhaps? Have you tried to see if this regression is present using OpenJDK 11? |
Yes, basically the results are the same. This regression is present in OpenJDK 11. I tested both Oracle and Adopt images using Docker on Mac. I also got similar results on native Linux and Mac Java runtime earlier. Native OpenSSL has been used in all cases (using static lib io.netty.tcnative.boringssl). Async-profiler data collected from image: amd64/openjdk:8-jrejava version:
image: amd64/openjdk:11-jrejava version:
image: adoptopenjdk/openjdk8:debianslim-jrejava version:
image: adoptopenjdk/openjdk11:debianslim-jrejava version:
|
@hamdiallam Hello, would you like to be so kind to assist with the issue? |
Hey! Sorry for not getting around to this. Just synced with some more folks internally. Our current builds and runtime environments are targeted towards JDK 8. JDK 11 is currently experimental and we are working towards moving towards JDK11. I'll spend some time to see if I can reproduce a regression in our integration environment using a JDK 11 build. If so, this is something that will have to be addressed as we move over. |
Also thanks for the time it took to produce this data. It's super helpful |
@andrievsky what happens if you use the |
Reading through #874, the suggestion seems to be that caching the SslContext might mitigate this issue. A similiar effect can be achieved with the ReloadingNetty4ServerEngineFactory which constructs the SslContext on an interval. Unlike the When I run it locally I see the following results: https://gist.github.com/rpless/df3245f9b778335fc66ae2a5ea99c280. The Assuming your SslContext does not change throughout the lifecycle of the process, there are some tradeoffs. The |
Significant TLS performance degradation after switching to AdoptOpenJDK 11 or above. Checked on Debian and Mac. Reproducible both locally and using k8s cluster with official AdoptOpenJDK images.
Platform: Debian, Mac
Sbt: 1.3.12
Scala: 2.13.2, 2.12.8, 2.11.12
Finagle: 20.5.0
Expected behavior
Similar CPU utilization in Java 8 and Java 11
Actual behavior
CPU utilization was about 3 times higher which also increase request processing time.
A profiler shows the issue directly related to TLS handling.
Steps to reproduce the behavior
A service code processing TLS conection
Please checkout complete project from https://github.com/andrievsky/finagle-tls
Java 8
sdk use java 8.0.222.hs-adpt
sbt run
ab -n 10000 -c 10 https://localhost:8443/
Java 11
sdk use java 11.0.7.hs-adpt
sbt run
ab -n 10000 -c 10 https://localhost:8443/
The text was updated successfully, but these errors were encountered: