Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

11–20 of 40 posts

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

#11

Post by V1 »

jsmeaton wrote: post #8

It would be interesting to see the difference with HAProxy if this line was removed: https://github.com/observing/balancerbattle/blob/master/hapr... 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. To be fair, I don't know what nginx does - whether connections are kept open or…

I'll re-run the test with the advised changes and see if the performance improves.

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

#12

Post by devicenull »

V1 wrote: post #10
devicenull wrote: post #9

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

Because we people obviously don't have a datacenter in our own basement. And the common mistake people make when benchmarking is running the servers on their own machine and then use the same machine to benchmark the server it's running. You need to have multiple (powerful) machines for this. And also, spinning up machines in the cloud is quite easy to do and allows people to reproduce the same test results because y…

You can reproduce them? So you can match the loads running on all the other VMs on the same host then?

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

#15

Post by ominous_prime »

gyepi wrote: post #7

> 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 From an operations standpoint, haproxy has other features (failover, cli management, clustering) that actually makes it a much better load balancer. I usuall…

In fact, I've often used nginx in front of haproxy as an easy ssl offloader (this was before stud was as stable and complete as it is now).

HAProxy also has a raw tcp mode, which is great when you have to balance non-http services.

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

#16

Post by count »

devicenull wrote: post #9

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

Unless you're looking for absolute performance numbers, then doing it on a vm on someone else's server is probably the most realistic deployment scenario.

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

#17

Post by V1 »

hoop wrote: post #13

I'd like to see Hipache tested against these as well. Hipache https://github.com/dotcloud/hipache

hipache is build on top of http-proxy. That's why I haven't included it in the tests. They have seem to have switched to a fork of http-proxy but there aren't big (if any) performance modifications as far as i've seen from the commits.

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

#18

Post by ominous_prime »

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.

I haven't worked on these in a couple years, but on real hardware, haproxy could push much more bandwidth. We could saturate 10Gb ethernet fairly easily at the time, which wasn't possible at all with nginx.

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

#19

Post by V1 »

jsmeaton wrote: post #8

It would be interesting to see the difference with HAProxy if this line was removed: https://github.com/observing/balancerbattle/blob/master/hapr... 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. To be fair, I don't know what nginx does - whether connections are kept open or…

The `http-server-close` option did not change anything. But by adding the ciphers it was able to squeeze out the same performance as Nginx. I'll update the tests accordingly. Thanks for the heads up!.

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

#20

Post by snaky »

V1 wrote: post #10
devicenull wrote: post #9

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

Because we people obviously don't have a datacenter in our own basement. And the common mistake people make when benchmarking is running the servers on their own machine and then use the same machine to benchmark the server it's running. You need to have multiple (powerful) machines for this. And also, spinning up machines in the cloud is quite easy to do and allows people to reproduce the same test results because y…

>You need to have multiple (powerful) machines for this

Oh really? For simple http 'hello world' comparision (where you are interested in relative numbers, not absolute ones) bechmark?

All you need is one old and slow laptop (with test contenders) and one modern and mighty (with test script). The only thing you have to be sure about is the test script can generate more load than test contenders can handle. Even if the old laptop isn't slow enough you can just add some predictable and stable load to cpu/disks/network/whatever is a bottleneck for them - you may use tools that are available for that or even quick & dirty hacks like one-liner 'while(1) {do some math}' that effectively make your 2-cores CPU 1-core while running with high system priority.

Post reply on HN