Forum Discussion
LanceLyons
Cirrus
CirrusSSL Full Proxy - SSL Re-Encryption performance degradation
Hi, We have traditionally been a shop that used SSL encryption to the F5 and decrypted text to webservers (https to F5 and http to webservers). We are being asked to encrypt the full route. We a...
Hello LanceLyons , Kai_Wilke provided a full list what can cause you such issues and if this helped please mark his reply as a solution. Outside of that if you are using a hardware device maybe see if hardware ssl ciphers are used for better performance as mentioned in https://support.f5.com/csp/article/K75983426 / https://support.f5.com/csp/article/K50459385 / https://support.f5.com/csp/article/K13213 and the /var/log/ltm if you are hitting some license limit for example.
Kai_Wilke
MVP
MVPHi Lance,
the performance impact is hard to guess.
We would need to get more details what "high traffic" means.
When it comes to SSL encryption its also important to understand if your "high traffic" means a couple long living session with high troughput or high connection setup rates with short living session with little troughput. Bandwidth is most likelynnot killing your CPU, key exchanges are a different story...
Its also important to know if you use one of the bigger F5 appliances including SSL-Offloading cards, or if you use lets say LTM-VE units on an slightly overbooked hypervisor.
Beside of this deep analytical and sometime esoterical approach, we could just try to listen to our guts. If lets say your CPU is right now on 20% with single-sided SSL encryption, you will most likely not end having 40% after enabling it... It would be just slighly above 20%... On the other hand if your CPU peeks already at 70% you are probably shredd your LTM if you going to put even more load on your CPU.
I assume your RPS graph is not 24/7 a constant line. So how about just testing server-side SSL in non-peek hours? Real world performance data is probably better than any mild guesses...
HTH and Cheers, Kai