05-15-2013 11:03 PM
Tricky... I do not believe we have ever done a side-by-side performance test with the HAProxy product.
A couple of third parties have done so:
OS tuning on HAProxy raised the performance to 5239 rps; RightScale did not report any attempts to apply OS tuning to aiCache or Zeus.
I don't think that the tests particularly stretched any of the load balancers. After further investigation, RightScale concluded that the bottleneck lay in the performance of the virtual network interfaces in the EC2 instance (approx 100k packets per second). I suspect that the Zeus performance figure was higher because of our support for HTTP keepalives (reducing network traffic) and software efficiencies (better use of kernel resources). Had RightScale enabled content compression in the load balancer, the Zeus figure would probably have increased by approximately 25% (assuming 50% compression).
More details here: Download Cloud Computing Management Platform White Paper | Cloud Computing Management Platform by RightScale (registration requried)
HAProxy: 1,800-2,500 requests per second
Zeus: 2,200-2,800 requests per second
nginx: 1,200-1,800 requests per second
(the loadbalancer.org and Barracuda devices they tested were hardware appliances with more resource available, so their results are not comparable)
It's not too surprising that given a basic load balancing configuration, running on identical hardware, several software load balancers give similar results.
No matter what software load balancer you chose, you can expect to be able upgrade the performance in the future, cost effectively and with relative ease. It's generally just a case of upgrading the underlying hardware (physical, virtual or cloud), or scaling horizontally (ensure your selected load balancer supports this).
A more useful consideration is to ask yourself what you want to achieve, today and in the future with the products you are considering (whichever you are looking at). HAProxy is a well-regarded product for load balancing web servers, but if you need to manipulate content, impose rate shapes on a set of users, make forwarding decisions based on the content of some XML, or 101 other complications you are likely to encounter in application delivery, it might not be the best tool (see Top Stingray Examples and Use Cases).
If you need to be able to phone a help desk to get support for your load balancer, or manage and load balance across multiple locations, use an integrated Application Firewall, or use visualization tools to understand your traffic, then again HAProxy might not be the best choice either (see Product Briefs for Stingray Traffic Manager).
With a software load balancer, performance is easy to upgrade. It's more important to focus on the functionality you need now and will need in the future.