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

Handling 1M websocket connections in Go

github.com

Post reply on HN
Print view View original

21–30 of 68 posts

Re: Handling 1M websocket connections in Go

#21

Post by e-r-a-n »

rdtsc wrote: post #18

Very cool. Noticed they had to go down to epoll: https://github.com/eranyanay/1m-go-websockets/blob/master/3_... that seems a bit too low level. Why not spawn 1m goroutines is that not feasible? This also reminds me of Erlang VM handling 2M for Whatsapp on a single server in 2012: https://blog.whatsapp.com/196/1-million-is-so-2011

The idea behind going all the way down to epoll is to reduce the memory footprint by around 30% otherwise, with every goroutine stack consuming 4-8KB, it's not feasible to go with 1goroutine-1websocket approach

Re: Handling 1M websocket connections in Go

#23

Post by ElijahLynn »

rdtsc wrote: post #18

Very cool. Noticed they had to go down to epoll: https://github.com/eranyanay/1m-go-websockets/blob/master/3_... that seems a bit too low level. Why not spawn 1m goroutines is that not feasible? This also reminds me of Erlang VM handling 2M for Whatsapp on a single server in 2012: https://blog.whatsapp.com/196/1-million-is-so-2011

Same. Reminded me of Erlang too!

Re: Handling 1M websocket connections in Go

#26

Post by wmf »

shereadsthenews wrote: post #11
ValleZ wrote: post #3

I thought you can make only 65k connections per port because of TCP limitations.

This comment appears routinely on HN. I'd love to find out how something so basic about TCP came to be so widely misunderstood.

Because almost everyone tests with one client IP and one server IP.

Re: Handling 1M websocket connections in Go

#27

Post by art0rz »

rhizome wrote: post #19

I'd like to see this kind of story combined with the "how to build a business" threads to discuss what kinds of business models and sizes require a million websocket connections to one process. 1M simultaneous users of a React (or other) app, is that a decently simple case? What are some sites that have this level of activity? I found a 5yr old article that says Spotify had 20MM simultaneous users then, but spread ov…

I have written a 1mm+ simultaneous user websocket server for a second screen app for a well known talent TV show in Node. It was running on a single server (with failovers and redundancies of course) just fine, but 99% of the server was just broadcasting. The hard part is sending single messages to users with user-specific content.

Re: Handling 1M websocket connections in Go

#28

Post by windlep »

rdtsc wrote: post #18

Very cool. Noticed they had to go down to epoll: https://github.com/eranyanay/1m-go-websockets/blob/master/3_... that seems a bit too low level. Why not spawn 1m goroutines is that not feasible? This also reminds me of Erlang VM handling 2M for Whatsapp on a single server in 2012: https://blog.whatsapp.com/196/1-million-is-so-2011

> Noticed they had to down to epoll: https://github.com/eranyanay/1m-go-websockets/blob/master/3_.... that seems a bit too low level.

Agreed, I'd be quite curious how many libraries in the Go ecosystem they can't use as a result. Either because the library spawns a goroutine, uses one under the hood, etc.

Having to drop to this level makes me wonder if it'd be better to just use a language better suited to this type of asynchronous networking (C/C++/Rust).

Re: Handling 1M websocket connections in Go

#29

Post by kjksf »

rhizome wrote: post #19

I'd like to see this kind of story combined with the "how to build a business" threads to discuss what kinds of business models and sizes require a million websocket connections to one process. 1M simultaneous users of a React (or other) app, is that a decently simple case? What are some sites that have this level of activity? I found a 5yr old article that says Spotify had 20MM simultaneous users then, but spread ov…

One of their slides (https://speakerdeck.com/eranyanay/going-infinite-handling-1m...) lists the use cases for such functionality and they are pretty broad (message queues, chat apps, notifications, social feeds, collaborative editing, location updates).

When you consider the price of the hardware and complexity of the system, it's obviously useful not just for handling 1M connections per host but also 10k connections per host.

If some other technology / framework can only do 1k connection per host, then you can per 10x less for hardware and have room to spare. And the system will simpler which means faster to develop.

Post reply on HN