Reduce server load by 20%+ with SSL Session ID Persistence

Last week I provided an explanation of the new SSL Session ID Persistence feature in LineRate v2.5.0. I made the claim that by using SSL Session ID Persistence can help by "Avoiding this excess computation by reusing the session identifier is one way to reduce load on the server." Internally, we tested and made sure this is really the case, but I didn't provide any data. Here is an overview.


Let's use the most simple configuration possible to display the behavior:

  • 1 Virtual IP, 1 Virtual Server, and some number of Real Servers configured on LineRate
  • 1 HTTPS client capable of session reuse such as Spirent Avalanche
  • Some number of backend servers terminating SSL and HTTP.

The LineRate system will not terminate the SSL but will inspect the traffic to get the session identifier and perform the persistence. This can now be easily tested by enabling/disabling the session identifier reuse on the Spirent Avalanche.


Since the session setup and negotiation is the thing which is being addressed, the HTTPS client will do a single very small HTTP GET of a 0 kb file on each connection. This maximizes the number of session (re)establishments. Here are the results in my test setup on an old 3.0 GHz Westmere machine:

.tg {border-collapse:collapse;border-spacing:0;border-color:#aaa;border-width:1px;border-style:solid;} .tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;border-color:#aaa;color:#333;background-color:#fff;} .tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;border-color:#aaa;color:#fff;background-color:#f38630;} .tg .tg-s6z2{text-align:center} .tg .tg-lyaj{background-color:#FCFBE3;text-align:center} .tg .tg-z2zr{background-color:#FCFBE3}
PersistenceHTTP Transactions
Per Sec
Server CPU Usage

Notice that there is a ~7% increase in total transactions per second and each backend server had lower CPU utilization by more than 20%.


Published Dec 01, 2014
Version 1.0

Was this article helpful?

No CommentsBe the first to comment