What impact does SSL have on load balancer performance? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Closed 9 years ago.

Improve this question

We use Citrix Netscaler load balancers that are used to front end our Web servers. What is the performance penalty of using SSL "all the way through", meaning SSL from end user to load balancer (load balancer contains the site certificate at 2048 strength) and then SSL from load balancer to each of the web servers (2048 again).

I am specifically interested in knowing the actual throughput numbers. Does using SSL impact the ability of the load balancer to serve traffic and if so, by what number. I am unable to obtain them off of Citrix's site.

Any help will be highly appreciated.

Answer 1

As the duration of the connections decreases, the overhead for using SSL increases. I'll look at two cases; the first case is when your connections are relatively long, averaging say 50 kbytes or more of average data transferred per connection, such that steady state throughput dominates; the second case is when your connections are short, say on the order of 1 kbyte per connection, such that connection setup dominates. My numbers will be based on the Citrix Netscaler data sheet here:

http://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/netscaler-data-sheet.pdf

In the first case, based on the numbers for "SSL throughput" and "System throughput", it appears that throughput for SSL connections, assuming the connections last long enough that setup costs are negligible, is approximately 25% to 75% of the throughput for unencrypted connections, depending on your specific configuration. This means that using SSL reduces throughput by roughly a factor of 2. Using SSL on both segments incurs that overhead roughly twice, so that would be roughly a factor of 3 slower than no encryption, or a factor of 1.5 slower than - that is, 67% as fast as - using encryption on only one segment. Depending on configuration that 67% factor might be as high as 80% (where SSL throughput is 75% of unencrypted throughput) or as low as 57% (where SSL throughput is 25% of unencrypted).

For short connections, especially short connections containing only one HTTP request each, the penalty for encryption is much higher, with "SSL transactions/sec" 10-30 times as high as "HTTP requests/sec". Essentially all of the time is spent setting up the transactions. In this case, setting up two SSL connections roughly doubles the amount of computation needed compared to setting up one SSL connection, so the amount of traffic that could be handled would be roughly half as much. I say "roughly", because depending on the asymmetric encryption parameters, the costs on the client side of the connection may be somewhat different from the cost on the server side of the connection, and the load balance will be on the server side of one of the connections, and on the client side of the other.

The bottom line is, I would expect capacity with SSL on both links to be somewhere in the range of 50% to 80% of capacity with SSL on only one of the links, if that is your question. Compared to unencrypted traffic, SSL on one link would provide between 3% and 75% as much capacity as no encryption, and SSL on both links would provide between 1.7% and 60% as much capacity as no encryption.