3

Our application is currently only a "regular" web app, with no fancy things like streaming HTTP or websockets. It's mostly a Rails app, served by a few (20 on 2 machines) Unicorn workers, proxied by a venerable nginx server which deals with load balancing.

This has been working quite well for the past year and the app now serves between 400 and 800 requests per second at any point during the day.

We're soon releasing 2 new APIs, which are both served by a Node application : a websocket one, as well as a long polling HTTP one. (the fancy thing like the Twitter streaming API where HTTP connections never end). They both use the same port on node and since the node app is stateless, we can certainly deploy a few of them to handle the traffic.

The app (node) is now deployed in 5 instances and are now listening on 5 different 'private' ports on the same host. We need to put something in front of them to load balance, but also something that is able to deal with sockets (either websocket or HTTP streaming) which are intended to stay 'up' for days.

The question is then : what? I read somewhere that HAProxy does a better job than Nginx at this. What do you recommend?

Tobu
  • 4,437
  • 1
  • 24
  • 31
Julien Genestoux
  • 609
  • 8
  • 19

2 Answers2

1

Nginx doesn't support WebSockets at all so you'll need to go with another load balancer. I've had good experiences with HAProxy. Check out this StackOverflow thread for a sample configuration: https://stackoverflow.com/questions/2419346/can-nginx-be-used-as-a-reverse-proxy-for-a-backend-websocket-server

clofresh
  • 141
  • 1
  • 5
0

Better yet, put nothing in front of it. DNS load balance + redirects. You will want intelligent node affinity eventually anyway, and you can get this from redirects. DNS load balancing is not great in the short term, but is workable in the long term as a good seed for balancing incoming connections.

Or, Julien, you could work with somebody like me that is solving this problem for people like you as a service. ;)

progrium
  • 101