9:08 a.m.
[
https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin....
]
Jan Stourac commented on WFWIP-160:
-----------------------------------
Hi [~ropalka], [~fjuma],
thanks for the looking into this. I've re-checked on my side too and I have to admit
that I suspect one of us is doing something differently. I can see there is some
performance improvement with current build of WildFly and JDK11.0.4, although this applies
also against TLSv1.2. As such there can still be seen quite insignificant performance drop
with TLSv1.3 when compared against TLSv1.2 in our scenario.
I've followed steps that Adam has described in the reproduction steps section and I
can see following data:
||Requests||Executions|| || ||Response Times (ms)|| || || || || ||Throughput||Network
(KB/sec)|| ||
||Label||#Samples||KO||Error %||Average||Min||Max||90th pct||95th pct||99th
pct||Transactions/s||Received||Sent||
|WFLY17-SNAPSHOT
TLSv1.2(a)JDK11.0.1|277697|0|0.00%|5.29|2|1029|6.00|7.00|11.00|925.72|1524.19|0.00|
|WFLY17-SNAPSHOT
TLSv1.3(a)JDK11.0.1|93551|0|0.00%|15.83|7|1048|17.00|19.00|24.00|311.85|513.45|0.00|
|WFLY17-SNAPSHOT
TLSv1.3(a)JDK11.0.4|138864|16|0.01%|10.65|5|1063|14.00|16.00|22.00|462.89|762.20|0.00|
|WFLY19-SNAPSHOT
TLSv1.2(a)JDK11.0.4|419609|0|0.00%|3.50|2|517|5.00|6.00|8.00|1398.79|2314.01|0.00|
|WFLY19-SNAPSHOT
TLSv1.3(a)JDK11.0.4|138843|18|0.01%|10.65|5|1067|13.00|14.00|17.00| 462.82|765.69|0.00|
|ROPALKA-SNAPSHOT
TLSv1.2(a)JDK11.0.4|363104|0|0.00%|4.05|2|425|5.00|6.00|8.00|1210.39|2002.34|0.00|
|ROPALKA-SNAPSHOT
TLSv1.3(a)JDK11.0.4|149742|25|0.02%|9.89|4|1070|12.00|14.00|18.00|499.16|825.83|0.00|
* WFLY17-SNAPSHOT = the [build that is referenced by
Adam|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]
in the reproduction steps
* WFLY19-SNAPSHOT:
** https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
** https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (wildfly-elytron version
updated)
** https://github.com/wildfly/wildfly/tree/master (wildfly-core version updated)
* ROPALKA-SNAPSHOT:
** https://github.com/ropalka/wildfly-elytron/tree/FJUMA-ELY-1706
** https://github.com/ropalka/wildfly-core/tree/FJUMA-WFCORE-4172
** https://github.com/ropalka/wildfly/tree/FJUMA-WFCORE-4172 (wildfly-core version
updated)
Note there are some errors present with TLSv1.3 and JDK 11.0.4 version, haven't looked
into them more thoroughly yet.
My environment:
{code}
$ uname -a
Linux dhcp-10-40-5-4.brq.redhat.com 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
JDK11.0.1
$ /home/jstourac/jdks/jdk-11/bin/java -version
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
JDK11.0.4
$ /home/jstourac/jdks/jdk-11.0.4+11/bin/java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.15.1, JRE 11 Linux amd64-64-Bit Compressed
References 20190717_286 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - fa49279450 based on jdk-11.0.4+11)
Apache JMeter v5.1.1
{code}
This is done for JSSE provider as described in reproduction steps section. Out of
curiosity, I'm gonna perform similar check also for wildfly-openssl security provider
and post my findings here too.
Fix throughput and response time differences between TLS 1.2 and TLS
1.3
------------------------------------------------------------------------
Key: WFWIP-160
URL: https://issues.jboss.org/browse/WFWIP-160
Project: WildFly WIP
Issue Type: Task
Components: Web (Undertow)
Reporter: Farah Juma
Assignee: Richard Opalka
Priority: Blocker
Attachments: jstourac-report.zip, results-tlsv12.zip, results-tlsv13.zip
Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular,
throughput is much lower (roughly three times lower) and response time is much higher
(roughly three times higher), which is not supposed to be the case. The underlying issue
seems to be in Undertow or XNIO, that is the code that actually gets invoked during the
TLS handshake process. Looking at CPU time, there is significantly more time being spent
in
[io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...]
with TLS 1.3 than with TLS 1.2.
Steps to reproduce (taken from EAP7-1022):
1. Build WildFly using the following feature branches or download a QE build of WildFly
[here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the
pom.xml file to use the version built in the previous step)
https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml
file to use the version built in the previous step)
2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
3. Download attached test plan
[TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
4. Configure and start server with TLSv1.3 and JDK 11:
{code}
connect
/subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
/subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
/subsystem=elytron/key-store=tls13:store()
/subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
/subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
batch
/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
run-batch
reload
{code}
5. Start jmeter with JDK 11 and downloaded test plan
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l
tlsv13.log -o results-tlsv13
{code}
6. Set server to use TLSv1.2
{code}
/subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
reload
{code}
7. Repeat same for TLSv1.2
{code}
export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l
tlsv12.log -o results-tlsv12
{code}
8. Compare results (there will be an index.html file in the results-tlsv12 and
results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)