Balancer Battle – Load testing HAproxy, Nginx and HTTP-Proxy's WebSocket support

&#62; nginx and haproxy were really close, it's almost not significant enough to say that one is faster or better then the other. But if you look at it from an operations stand point. It's easier to deploy and manage a single nginx server instead of stud and haproxy<p>From an operations standpoint, haproxy has other features (failover, cli management, clustering) that actually makes it a much better load balancer. I usually install all three haproxy, stud, nginx because they are each very good in their specific niche. As for the simplicity of installation, that can be handled with a configuration manager.

As a simple reverse proxy for small setups, there is almost no difference between the two, especially when running on a VM. You do miss many of the advanced balancing features in haproxy, but again, this config was a basic reverse proxy, not really load-balancing anything.<p>I haven't worked on these in a couple years, but on real hardware, haproxy could push <i>much</i> more bandwidth. We could saturate 10Gb ethernet fairly easily at the time, which wasn't possible at all with nginx.

It would be interesting to see the difference with HAProxy if this line was removed: <a href="https://github.com/observing/balancerbattle/blob/master/haproxy.cfg#L13" rel="nofollow">https://github.com/observing/balancerbattle/blob/master/hapr...</a><p>What the option does is close the connection between the proxy and the backend so that HAProxy will analyse further requests instead of just forwarding to the already established connection.<p>To be fair, I don't know what nginx does - whether connections are kept open or shut down - so I'm not sure that it'd be a fair comparison.<p>Also interesting are the HAProxy built in SSL times. I'm surprised they're so slow. Perhaps the cipher is also the culprit. The cipher can also be specified in HAProxy.<p><pre><code> bind *:8080 ssl crt /root/balancerbattle/ssl/combined.pem ciphers RC4-SHA:AES128-SHA:AES:!ADH:!aNULL:!DH:!EDH:!eNULL</code></pre>

How many requests are made per connection? In order to better gauge performance we need a 3-axis plot, where the response rate is measured against various request-per-connection values and connection rates.

&#62; I had the wrong ciphers configured. After some quick tweaking and a confirmation using openssl s_client -connect server:ip<p>Is this in the nginx config? Can anybody elaborate a bit further? Here is what I am currently using in my nginx config for ssl:<p><pre><code> ssl_session_cache shared:SSL_CACHE:8m; ssl_session_timeout 5m; # Mitigate BEAST attacks ssl_ciphers RC4:HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on;</code></pre>

Is it just me, or are all these latency numbers terrible? For a local echo server I would expect mean latency at or below 1ms.

I'd like to see Hipache tested against these as well. Hipache <a href="https://github.com/dotcloud/hipache" rel="nofollow">https://github.com/dotcloud/hipache</a>

Even though RC4 is fast you really shouldn't be using it: <a href="http://www.isg.rhul.ac.uk/tls/" rel="nofollow">http://www.isg.rhul.ac.uk/tls/</a>

Why do people always benchmark on virtual machines running on someone else's server, and expect meaningful results?

Where is Varnish in this mix?