-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
11.0.11
-
x86_64
-
linux
ADDITIONAL SYSTEM INFORMATION :
We have tried openjdk 11.0.8 and 11.0.11 on several linux kernels (4.15, 5.4, 5.8) using Ubuntu 18.04, 20.04 and 20.10. The openjdk versions tested were both from ubuntu packaging and from tgz openjdk binaries
A DESCRIPTION OF THE PROBLEM :
We operate a crawler based on BUbiNG. With 11.0.{8..10}, we have a performance of 700 pages/s. Since we switched to 11.0.11, we have a performance that tops at ~400pages/s. The apparent culprit is time spent in StartHandshake. We have tried to re-enable TLS1 and TLS1.1 since they were disabled in 11.0.11, but the outcome is the same. The problem (i.e. longer handshakes) only seem to occur when there are more than a certain amount of simultaneous connections.
REGRESSION : Last worked in version 11
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Perform a lot of HTTPS connections for a long period of time, the time spent in connections climbs very fast as the number of simultaneous connection grows.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
11.0.11 Should have the same performance than the 11.0.8
CUSTOMER SUBMITTED WORKAROUND :
No workaround found.
FREQUENCY : always
We have tried openjdk 11.0.8 and 11.0.11 on several linux kernels (4.15, 5.4, 5.8) using Ubuntu 18.04, 20.04 and 20.10. The openjdk versions tested were both from ubuntu packaging and from tgz openjdk binaries
A DESCRIPTION OF THE PROBLEM :
We operate a crawler based on BUbiNG. With 11.0.{8..10}, we have a performance of 700 pages/s. Since we switched to 11.0.11, we have a performance that tops at ~400pages/s. The apparent culprit is time spent in StartHandshake. We have tried to re-enable TLS1 and TLS1.1 since they were disabled in 11.0.11, but the outcome is the same. The problem (i.e. longer handshakes) only seem to occur when there are more than a certain amount of simultaneous connections.
REGRESSION : Last worked in version 11
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Perform a lot of HTTPS connections for a long period of time, the time spent in connections climbs very fast as the number of simultaneous connection grows.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
11.0.11 Should have the same performance than the 11.0.8
CUSTOMER SUBMITTED WORKAROUND :
No workaround found.
FREQUENCY : always
- duplicates
-
JDK-8268427 Improve AlgorithmConstraints:checkAlgorithm performance
-
- Resolved
-