You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on #46677 I have been stumbled on / investigated on another throughput related bottleneck. This time specifically tied to HTTPS/TLS when reading the streamed POST body as InputStream.
While I am aware that HTTPS/TLS increases load and may lower throughput, it is factor 30 slower than with HTTP, which seems unreasonable slow to me.
In our testsytem we measured:
~600-700MiB/s for plain HTTP on loopback
~20MiB/s for HTTPS on loopback
~400MiB/s when offloading TLS to nginx in a docker container running on the same machine
So clearly the crypto computing by itself should not be the problem.
In further tests I also used the tcnative binding for netty and configured it to use the openssl library as tls engine via HttpServerOptionsCustomizer and setting the SslEngineOption to OpenSSLEngineOptions.
With this setting I was able to achive ~210MiB/s which is enough for my case even though it is still half the value of offloading tls to nginx and reverse proxying. Perhaps there is a deeper problem here i dont see or just unavoidable overhead comming with java+tls - I dont know.
Nevertheless would it maybe make sense to offer this simple setting solution via Quarkus config setting similar to quarkus.vertx.prefer-native-transport. For example quarkus.vertx.use-native-openssl ?
Thats cool! Thanks for pointing it out. I did not find it while searching for anything similar - probably because I focused on the performance aspect not the setting itself.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Following up on #46677 I have been stumbled on / investigated on another throughput related bottleneck. This time specifically tied to HTTPS/TLS when reading the streamed POST body as InputStream.
While I am aware that HTTPS/TLS increases load and may lower throughput, it is factor 30 slower than with HTTP, which seems unreasonable slow to me.
In our testsytem we measured:
So clearly the crypto computing by itself should not be the problem.
These numbers and tests are taken and done with https://github.com/werpat/quarkus-tls-inputstreamtest/
In further tests I also used the tcnative binding for netty and configured it to use the openssl library as tls engine via HttpServerOptionsCustomizer and setting the SslEngineOption to OpenSSLEngineOptions.
With this setting I was able to achive ~210MiB/s which is enough for my case even though it is still half the value of offloading tls to nginx and reverse proxying. Perhaps there is a deeper problem here i dont see or just unavoidable overhead comming with java+tls - I dont know.
Nevertheless would it maybe make sense to offer this simple setting solution via Quarkus config setting similar to
quarkus.vertx.prefer-native-transport. For examplequarkus.vertx.use-native-openssl?All reactions