TLS 1.3 Taking too much CPU

Question

Hi! I'd like to know why does TLS 1.3 take too much CPU?

Comments

Just 3-5 threads of concurrent HTTPS requests over TLS 1.3 connection makes my CPU work at 99%

Answer 1

TLS 1.3 CPU usage indeed seems to be a bit too much in many scenarios, and we do plan improvements in this area in the future. (Update: This has improved a lot in R6.0 release!)

However, at the moment, we are still busy adding some features such as OCSP that are perceived us must-have by customers using Rebex HTTPS on legacy platforms, which are currently the component's major use case.

Also, due to the fact that Rebex HTTPS is mostly targeted at legacy platforms, it's HTTP internals are mostly implemented using classic synchronous code, which is not a good match for our fully-asynchronous TLS 1.3 implementation.

Therefore, users looking for performance and scalability are advised to consider using the low-level Rebex TLS API instead and check out the HttpsGet sample app - when compiled for .NET 5.0 and executed in quiet mode, its CPU usage is considerably lower (even compared with the same app compiled for .NET 4.x).

Comments

Hello.
When downloading with TLS1.3 using Rebex HTTPS (R6.0), CPU usage is 2 to 2.5 times higher than that of TLS 1.2.
The .Net version I use is 4.8.
This is a lot better than the R5.6, but still high.
Is there any way to reduce CPU usage?

---

Hello lanopk, which edition of Rebex binaries do you use? Do you use "net-4.0" binaries or "net-4.6" binaries?

---

I am using .net 4.6 binary.

---

Well, we are still improving TLS 1.3, so hopefully the CPU usage will get better in future releases. But still, the synchronous internals of HTTP code vs fully asynchronous TLS 1.3 code is not a good match, so there will be some performance hit for that until we address it as well.