5 ms·
I'm not exactly sure what that has to do with the throughput of TLS, especially considering that it's 99% likely that its implemented in a native library (opens
by pmalynin 8y ago
I'm not exactly sure what that has to do with the throughput of TLS, especially considering that it's 99% likely that its implemented in a native library (openssl, etc).
- halbritt 8y agoThe problem is that it's not implemented in the native library. That's why the throughput is so abysmal.
- anotherhue 8y agoIt also prevents use of the sendfile optimisation -- meaning a lot of Kafka perf disappears.
- halbritt 8y agoOne wonders why this was downvoted.
- deanmoriarty 8y agoJava TLS implementation is 99.9% implemented in Java itself (look at JSSE), openssl was ditched a long, long time ago. Not that I would necessarily expect the throughput to be significantly different than the native version considering the good performance of JITted Java, but was just commenting on your assumption.
- pmalynin 8y agoOh, I didn't know that, thanks for the clarification. I mostly work with C++, Python and Node in my day to day, so my assumptions are biased.
- 75dvtwin 8y agoTake a look at conscrypt https://github.com/google/conscrypt https://github.com/google/conscrypt According to reports into Jetty folks, using conscript for TLS, gives 10x improvements https://webtide.com/conscrypting-native-ssl-for-jetty/ https://webtide.com/conscrypting-native-ssl-for-jetty/ Note, that, from what I read, conscrypt is not compiled for any of the BSDs so if you are testing there, you will have to compile conscrypt yourself