What nginx or haproxy setup is suggested for target 100K concurrent websocket connections? What I think, a single nginx will not be able to take such traffic as well as concurrent connections. How should traffic to nginx/haproxy be split (DNS lvl or any Amazon/Google option available)? How much concurrent websockets a single nginx be able to handle?

Tried gathering relevant information from google search and SO posts.

  • Currently I am restructuring my app architecture to use Websocket totally, no ajax. We have around 12-13k peak users, but they tend to open multi-browser-tabs. Right now target is to support 50K, but just to be safe and know what kind of websocket load-balancing people use, I have elevated target to 100K.
    – Ravi Kumar
    Sep 28 '15 at 9:25
  • @AD7six that duplicate is waste of time. I asked about websocket. Please read the question.
    – Ravi Kumar
    Sep 29 '15 at 6:09
  • @DukeLion thanks, I am learning from people like you. Did you read my question, I am not asking what benchmarks are available, rather how the connection/traffic pooling should be structured for high throughput.
    – Ravi Kumar
    Sep 29 '15 at 6:12
  • Great, @RaviKumar, please consider editing your question clarifying that.
    – DukeLion
    Sep 29 '15 at 6:53
  • 1
    Read this - mrotaru.wordpress.com Sep 29 '15 at 8:04

There are people running chat servers behind haproxy load balancers at even higher loads. The highest load that was reported to me in private e-mail (with the copy of the stats page) was at around 300k connections per process (hence 600k sockets). Note that under Linux by default a process is limited to 1M file descriptors (hence 500k end-to-end connections), but that can be tweaked in /proc.

The most important thing to consider at such loads is the amount of RAM you need. The kernel-side socket buffers will always require at least 4kB per direction per side, hence 16kB minimum per end-to-end connection. HAProxy 1.5 and lower will have two buffers per connection (eg: 4kB buffers are enough for websocket). 1.6 can run without those buffers and only keep them allocated for the rare connections with data. So at least that's 16 GB of RAM per million of connection, or around 24 GB with older versions. It may be worth spreading this over multiple processes on SMP machines to reduce the latency. Keep in mind that in order to simply establish 1M connections, it can take 10 seconds at 100k conns/s. All these connections induce some work for a few bytes each, and dealing with 1M active connections will definitely induce an important work and a high load on the system.

  • wow, thanks Willy. These type of information I am seeking for, so I can get some direction for researching over more.
    – Ravi Kumar
    Sep 29 '15 at 8:15
  • I have questions, why there are two sockets per connection, is it IN + OUT buffered socket (will use file descriptor). Is 1M limit default to all Linux distro. I am guessing its same as ulimit, and that would be 1024 on my ubuntu. If thats the case, I can raise it (to what max limit).?
    – Ravi Kumar
    Sep 29 '15 at 8:18
  • 1
    you have two sockets because the first one is between the client and haproxy and the second one between haproxy and the server. The million is the kernel's default and I'm not aware of any distro changing it by default, but it's just a sysctl, it's unlimited. The 1024 you're seeing in ulimit is for non-root users, root is allowed to raise the limit up to this sysctl :-) Oct 21 '15 at 20:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.