HAProxy and nodeJs server using SocketIO

906 views
Skip to first unread message

hd nguyen

unread,
Jul 27, 2012, 1:19:26 AM7/27/12
to nod...@googlegroups.com

Hi all,

I did some google search but not find any detail document described about combination between HAProxy and Nodejs apps(use socketIO), something for me to believe that it can work well.

I have another option is Nginx, but just want you guys help me to confirm that is it possible to use HAproxy as load balancer for Nodejs server farm (using SocketIO to transfer data)?

Thanks in advance.
--
Nguyen Hai Duy
Mobile : 0914 72 1900
Yahoo: nguyenhd_lucky

dvbportal

unread,
Jul 27, 2012, 2:08:45 AM7/27/12
to nod...@googlegroups.com
In the past such setups didn't work. Maybe the latest versions are doing better. A tested variant though is Nodejitsu's proxy. It can do websockets and load balance with a bit additional code.

- Hans

hd nguyen

unread,
Jul 27, 2012, 2:30:55 AM7/27/12
to nod...@googlegroups.com
So I can understand that till now this combination is not working well?

On Fri, Jul 27, 2012 at 1:08 PM, dvbportal <dvbp...@gmail.com> wrote:
In the past such setups didn't work. Maybe the latest versions are doing better. A tested variant though is Nodejitsu's proxy. It can do websockets and load balance with a bit additional code.

 - Hans

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Arnout Kazemier

unread,
Jul 27, 2012, 3:36:42 AM7/27/12
to nod...@googlegroups.com
There is nothing wrong with using HAproxy to load balance WebSocket / Socket.IO requests. It works perfectly fine
and is a proven and well established technology stack. You just need to make sure that you run it TCP mode.. Here
is some example configuration on working with Socket.IO + HAProxy + stud; https://github.com/dvv/farm

Nginx will probably not work because it doesn't support HTTP 1.1 for upstream proxies. If you don't want to complicate
your stack with different technologies, you can indeed use the excellent Nodejitsu HTTP proxy. https://github.com/nodejitsu/node-http-proxy

hd nguyen

unread,
Jul 27, 2012, 3:48:33 AM7/27/12
to nod...@googlegroups.com
Thanks guys,

As  Arnout said, Arnout we should have 2 options for this case: HAproxy or node-http-proxy module.

Anyone can help me figure out which option is the better choice for enterprise app?
 node-http-proxy is being used by Nodejitsu, but cannot find a trustworthy site/source using HAproxy+websocket/socket.IO ?!

Ben Noordhuis

unread,
Jul 27, 2012, 7:55:08 AM7/27/12
to nod...@googlegroups.com
On Fri, Jul 27, 2012 at 9:36 AM, Arnout Kazemier <in...@3rd-eden.com> wrote:
> Nginx will probably not work because it doesn't support HTTP 1.1 for
> upstream proxies.

That's no longer true as of nginx 1.2.0. Websocket support is targeted
for 1.4.0.

Jimb Esser

unread,
Jul 27, 2012, 3:05:33 PM7/27/12
to nod...@googlegroups.com
We're using HAProxy+stud+WebSockets/SecureWebSockets.  When I was doing some performance testing, stud was notably faster than all of the other alternatives for the latency/CPU usage of SSL termination (this was on node 0.4.x at the time, but stud was about 2x as fast as node or nginx).

HAProxy is fine, but if you want to put your SSL termination behind your load balancer (otherwise quickly that becomes your bottleneck if all of your traffic is https), you need to run it in TCP mode.  HAProxy for HTTP (non-secure) seemed to work fine for WebSockets even when not in TCP-mode.

If in TCP mode, and you want IP address of your connections, it's a bit of work since you can't do header re-writing.  Need to have HAProxy configured with send-proxy, and stud with --read-proxy and --write-proxy or --proxy-proxy (look in stud's pull requests for these), and node needs to be patched with the ability to read the proxy line before starting HTTP parsing (requires building node yourself).

  Jimb Esser
  Cloud Party, Inc


On Friday, July 27, 2012 12:48:33 AM UTC-7, hd nguyen wrote:
Thanks guys,

As  Arnout said, Arnout we should have 2 options for this case: HAproxy or node-http-proxy module.

Anyone can help me figure out which option is the better choice for enterprise app?
 node-http-proxy is being used by Nodejitsu, but cannot find a trustworthy site/source using HAproxy+websocket/socket.IO ?!
On Fri, Jul 27, 2012 at 2:36 PM, Arnout Kazemier wrote:
There is nothing wrong with using HAproxy to load balance WebSocket / Socket.IO requests. It works perfectly fine
and is a proven and well established technology stack. You just need to make sure that you run it TCP mode.. Here
is some example configuration on working with Socket.IO + HAProxy + stud; https://github.com/dvv/farm

Nginx will probably not work because it doesn't support HTTP 1.1 for upstream proxies. If you don't want to complicate
your stack with different technologies, you can indeed use the excellent Nodejitsu HTTP proxy. https://github.com/nodejitsu/node-http-proxy

On Friday 27 July 2012 at 08:30, hd nguyen wrote:

So I can understand that till now this combination is not working well?

On Fri, Jul 27, 2012 at 1:08 PM, dvbportal wrote:
In the past such setups didn't work. Maybe the latest versions are doing better. A tested variant though is Nodejitsu's proxy. It can do websockets and load balance with a bit additional code.

 - Hans

--
Nguyen Hai Duy
Mobile : 0914 72 1900
Yahoo: nguyenhd_lucky


hd nguyen

unread,
Jul 30, 2012, 3:17:29 AM7/30/12
to nod...@googlegroups.com
@Jimb: thank you so much for your useful comment :)

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

hd nguyen

unread,
Jul 30, 2012, 5:54:47 AM7/30/12
to nod...@googlegroups.com
@Jimb Esser: with that configuration, eg a client first connect to socket server1, everything is ok, but server1 is crashed, so the system will redirect and make new connection to socket at server2 automatically, right?

Is everything transparent to developer and end user or we need to handle it by code (using Redis to store client's information....)?

Regards,

Jimb Esser

unread,
Jul 30, 2012, 3:02:33 PM7/30/12
to nod...@googlegroups.com
If a client is connected to server1 and server1 goes down, it loses its WebSocket connection, but any new connections would automatically go to server2. I don't think there's anything which would automatically keep the WebSocket connection from client to proxy, and redirect the traffic on the back-end (it's not actually possible without ridiculous amounts of buffering - if you were in the middle of sending a very large fragmented packet, it would require the proxy to buffer the entire thing, or just drop it but then you're effectively dealing with packet loss, and madness lies in that direction).

In our case, in the event of a crash, the client gets a WebSocket disconnect event, and we just reconnect (actually just refresh the page, but could do a reconnect).

With any TCP-level load balancing, connections go to arbitrary servers, so if you need to correlate multiple requests to the same user, then, yes you need to use something external to share information between the servers.  That being said, a single WebSocket connection is guaranteed to send all packets to the same server, so if all of your stateful application logic is done over WebSockets, there's no need for any external tracking.  You can also somewhat work around this by configuring the HAProxy to load balance based on source IP address, or if HTTPS-only, based on the client's SSL ID peeked out of the SSL stream.  We went the route of having virtually everything stateful done over the WebSocket connection, with a small amount of the usual externally stored session information so that when a POST/file upload goes to a different server, it can correlate it with the appropriate user.

hd nguyen

unread,
Jul 30, 2012, 8:10:13 PM7/30/12
to nod...@googlegroups.com
+1 for Jimb :)

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Reply all
Reply to author
Forward
0 new messages