Some of the most common questions we get at Loadbalancer.org are performance related. It is quite difficult to give a straight answer to these questions as the real answer is the slightly unsatisfactory, " Um... well it depends on your application...". The following graph showing HAProxy performance for different object sizes gives you a much better idea of the problem:

As you can quickly see from this graph, the number of connections/s, bandwidth and object size are all closely correlated. Depending on your application and usage pattern you will get vastly different throughput results from your load balanced cluster.

Generally even our smallest appliance can fill a 1GB pipe (we have several customers easily doing 2Gb+), But we do have some guidelines for our sales guys:

  • For deployments using Layer 7 and expecting a very large number of connections/second, or deployments with a large number of SSL TPS - This is very CPU intensive so we generally recommend our MAX or Dell hardware.
  • For Layer 7 deployments with very large numbers of long connections i.e. Exchange 2010 with 5000+ users - This is very memory intensive so we generally recommend our MAX or Dell hardware or the ENTERPRISE VA.

So one of the problems that load balancer vendors have is specifying good looking numbers i.e big ones, relating to their load balancer performance. Loadbalancer.org is just as guilty as the other vendors in using best case scenarios for performance:
matrix
Does this specification mean that you can get 60,000 HTTP requests a second AND 1.5GBps throughput? I don't think so...

Does this specification mean that you can get 500 SSL TPS on our least powerful appliance with a 2048 Bit key? I don't think so...

Loadbalancer.org SSL stats are all based on 1024 Bit keys...
One of our guys will shortly write a blog on the full test process we use + a comparison of the different cyphers and their effect on performance, he even has a $16K Thales crypto card he's been putting through its paces for an interesting comparison of SSL Hardware/ASIC Acceleration versus generic multi-core CPUs...