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

41–50 of 68 posts

Re: Handling 1M websocket connections in Go

#41

Post by kasey_junk »

kjksf wrote: post #32
jondubois wrote: post #15

These kinds of benchmarks are not very meaningful. I think that pretty much any modern framework/language can handle at least 1 million idle WebSockets. It's much more interesting to measure performance when you start sending messages through them at regular intervals.

When people rewrite system from X where X in (Python, Ruby, Node, Clojure) to Go they usually see at least 10x improvement. This is just one recent example: https://www.infoq.com/articles/api-gateway-clojure-golang The money quote: "The end result enabled us to reduce 25 instances (c4 xlarge) running Clojure code - able to process 60 concurrent requests, to two instances (c3.2xlarge) running Go code able to support ~…

Or Java or C# or basically any non-interpreted language.

Re: Handling 1M websocket connections in Go

#42

Post by cdoxsey »

spenrose wrote: post #40

An issue with Go channels and high-performance networking from 2016: "There was one fundamental mistake made, however, which is that we shouldn't have used channels. ... First, they don't perform well enough. ... Second, they make it very hard to prevent message loss. ... Third, the buffered channels mean that Heka consumes much more RAM than would be otherwise needed" https://mail.mozilla.org/pipermail/heka/2016-May…

Not really a networking issue. Channels are (relatively) inefficient for small payloads. With a decent payload size they're almost never the bottleneck in a real-world program. You really have to benchmark it.

It sounds like in this case the message-loss-prevention rendered the original design flawed. I don't see any reason why you couldn't use an on-disk queue in Go vs other languages... though the cgo overhead of the lua binding sounds like it was also an issue.

Re: Handling 1M websocket connections in Go

#43

Post by sudhirj »

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’m working on https://whatsgoingon.in that needs this and uses the base technique - which is actually pretty cool and good enough. I can live with 20GB of RAM for a million connections, given that it’s a paid product (live blogging)

Re: Handling 1M websocket connections in Go

#44

Post by piranha »

kjksf wrote: post #32
jondubois wrote: post #15

These kinds of benchmarks are not very meaningful. I think that pretty much any modern framework/language can handle at least 1 million idle WebSockets. It's much more interesting to measure performance when you start sending messages through them at regular intervals.

When people rewrite system from X where X in (Python, Ruby, Node, Clojure) to Go they usually see at least 10x improvement. This is just one recent example: https://www.infoq.com/articles/api-gateway-clojure-golang The money quote: "The end result enabled us to reduce 25 instances (c4 xlarge) running Clojure code - able to process 60 concurrent requests, to two instances (c3.2xlarge) running Go code able to support ~…

That article is anything but useful. They have spent significantly more time designing and writing app in Go than their prototype in Clojure and now it’s faster? What a surprise!

Re: Handling 1M websocket connections in Go

#46

Post by doublerebel »

cdoxsey wrote: post #37
e-r-a-n wrote: post #21

Earlier quoted context omitted.

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

That's what, 8GB of ram? A lot for a laptop... but not too much for a server.

30% extra RAM is a very noticeable server expense.

Re: Handling 1M websocket connections in Go

#47

Post by apta »

kjksf wrote: post #32
jondubois wrote: post #15

These kinds of benchmarks are not very meaningful. I think that pretty much any modern framework/language can handle at least 1 million idle WebSockets. It's much more interesting to measure performance when you start sending messages through them at regular intervals.

When people rewrite system from X where X in (Python, Ruby, Node, Clojure) to Go they usually see at least 10x improvement. This is just one recent example: https://www.infoq.com/articles/api-gateway-clojure-golang The money quote: "The end result enabled us to reduce 25 instances (c4 xlarge) running Clojure code - able to process 60 concurrent requests, to two instances (c3.2xlarge) running Go code able to support ~…

> To do better than Go you would have to drop to C++ or Rust.

C++ and Rust yes, but also Java and .NET.

Re: Handling 1M websocket connections in Go

#48

Post by weberc2 »

apta wrote: post #47
kjksf wrote: post #32

Earlier quoted context omitted.

When people rewrite system from X where X in (Python, Ruby, Node, Clojure) to Go they usually see at least 10x improvement. This is just one recent example: https://www.infoq.com/articles/api-gateway-clojure-golang The money quote: "The end result enabled us to reduce 25 instances (c4 xlarge) running Clojure code - able to process 60 concurrent requests, to two instances (c3.2xlarge) running Go code able to support ~…

> To do better than Go you would have to drop to C++ or Rust. C++ and Rust yes, but also Java and .NET.

In my experience Java, C#, and Go are roughly on par. Go is a bit easier to optimize though.

Re: Handling 1M websocket connections in Go

#50

Post by rakenodiax »

kasey_junk wrote: post #41
kjksf wrote: post #32

Earlier quoted context omitted.

When people rewrite system from X where X in (Python, Ruby, Node, Clojure) to Go they usually see at least 10x improvement. This is just one recent example: https://www.infoq.com/articles/api-gateway-clojure-golang The money quote: "The end result enabled us to reduce 25 instances (c4 xlarge) running Clojure code - able to process 60 concurrent requests, to two instances (c3.2xlarge) running Go code able to support ~…

Or Java or C# or basically any non-interpreted language.

In this case, Clojure is already running on the JVM
Post reply on HN