Does round-robin load balancing affect HTTPS performance?
Scenario:
- Small web farm behind a hardware load balancer
- No need for server affinity. If one server goes down, another can and should take over.
- Part of the system requires HTTPS. This is terminated at the servers. SSL certificates are installed on each server.
- The servers have more than enough capacity, so no worries about which server to route a request to (even if one server is out of rotation.)
With this in mind, it seemed like the most obvious choice for a load balancing strategy was a simple round-robin approach. Source IP based balancing seemed it would be difficult to test, and cookie-based balancing doesn't seem to work with SSL.
I'm worried though that browsers might be re-negotiating their HTTPS connections each time a page is served by a different web server, making the website a lot slower than it should be.
So my questions:
- Would this indeed be a problem? Or are load balancers clever enough to somehow only do 1 SSL handshake even when content is served from multiple servers?
- Are there any tools (Windows) that one can use to easily monitor SSL handshakes, HTTP keepalives etc when surfing a website?
- If we do have a problem here, how can we solve it? (The obvious solution I guess is to offload SSL at our load balancer, but our current hardware doesn't support that, so any other solutions would be preferable at this stage.)
Consecutive calls using keepalives are part of the same TCP flow, so only one SSL negotiation is involved, and they should all go to the same server.
Requests without keepalives will be independent flows, each requiring separate SSL negotiation.
So yes, round-robin should be fine.