ProxySG is experiencing high CPU loads even though throughput on the device is relatively low.

There are multiple factors that can lead to high CPU in SSL and Cryptography components. In this particular case the issue was caused by a lack of affinity on the load balancers.

Analysis showed that the SSL session cache on the ProxySGs was full, further analysis showed that the reason the cache was filling up was that the load balancers were not sending users back to the same ProxySG, but moving them from one proxy to another. As a result, the ProxySG was continuously having to, not only recreate new entries in the SSL session cache but complete a full SSL handshake as opposed to using the Session ID, as the original entries are invalidated once the user is moved to a different ProxySG.

The SSL session cache is used to help reduce CPU load on the ProxySG, however, it relies heavily on the fact that each connection can be uniquely identified (the session ID) and reused, (see RFC5246 for details on Session ID). If the load balancers are moving users between proxies we negate the efficiency of the session cache and this results in higher CPU and slower browsing speeds for the users.

To prevent this, load balancers should be configured so that the same user is always sent to the same ProxySG for as long as possible.

Currently the size of the SSL session cache is fixed and based on the specific model of ProxySG, the amount of memory dedicated to the SSL session cache is based on the amount of memory the ProxySG has installed, for example, a S500-10 will have approximately 110K of memory assigned to the session cache whereas the S500-30 will have approximately 220K.

Entries in the session cache have a time to live for 1 hour, again this setting cannot be modified.