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

An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

researchgate.net

Post reply on HN
Print view View original

21–30 of 45 posts

Re: An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

#21

Post by initplus »

vandot wrote: post #7
latch wrote: post #6

Their explanation for why Go performs badly didn't make any sense to me. I'm not sure if they don't understand how goroutines work, if I don't understand how goroutines work or if I just don't understand their explanation. Also, in the end, they didn't use the JSON payload. It would have been interesting if they had just written a static string. I'm curious how much of this is really measuring JSON [de]serialization…

They didn’t use goroutines, which is explains the poor perf. https://github.com/matttomasetti/Go-Gorilla_Websocket-Benchm... Also, this paper is from Feb 2021.

http.ListenAndServe is implemented under the hood with a new goroutine per incoming connection. You don't have to explicitly use goroutines here, it's the default behaviour.

Re: An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

#22

Post by necrobrit »

initplus wrote: post #21
vandot wrote: post #7

Earlier quoted context omitted.

They didn’t use goroutines, which is explains the poor perf. https://github.com/matttomasetti/Go-Gorilla_Websocket-Benchm... Also, this paper is from Feb 2021.

http.ListenAndServe is implemented under the hood with a new goroutine per incoming connection. You don't have to explicitly use goroutines here, it's the default behaviour.

Yes _however_ the nodejs benchmark at least is handling each message asynchronously, whereas the go implementation is only handling connections asynchronously.

The client fires off all the requests before waiting for a response: https://github.com/matttomasetti/NodeJS_Websocket-Benchmark-... so the comparison isn't quite apples to apples.

Edit to add: looks like the same goes for the c++ and rust implementations. So I think what we might be seeing in this benchmark (particularly the node vs c++ since it is the same library) is that asynchronously handling each message is beneficial, and the go standard libraries json parser is slow.

Edit 2: Actually I think the c++ version is async for each message! Dont know how to explain that then.

Re: An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

#23

Post by ndusart »

zo1 wrote: post #18

Was this published as-is to some sort of prominent CS journal? I honestly can't tell from the link. If that's the case, I'm very disappointed and would have a few choice words about the state of "academia".

Yes, that would be concerning indeed...

The author couldn't tell why he didn't manage to make run the C or python program but figured it is probably the blame of the language for some obscure reasons.

He also mentioned that he should have implemented multithreading in C++ to be comparable with Node, but meh that's probably also not of his concern, let compare them as is ^^`

Also he doesn't mention the actual language of the library used, but that would have voided the interest of the article, so I quite may understand that omission :P

But at the end, nothing can be learned from this and it is hard to believe it is what "research" can produce

Re: An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

#24

Post by jand »

donjoe wrote: post #16
windlep wrote: post #8

Earlier quoted context omitted.

I was under the impression that the underlying net/http library uses a new goroutine for every connection, so each websocket gets its own goroutine. Or is there somewhere else you were expecting goroutines in addition to the one per connection?

Which is perfectly fine. However, you will be able to process only a single message per connection at once. What you would do in go is: - either a new goroutine per message - or installing a worker pool with a predefined goroutine size accepting messages for processing

Another option is to have a read-, and a write-pump goroutine associated with each gorilla ws client. I found this useful for gateways wss *.

Re: An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

#26

Post by josephg »

necrobrit wrote: post #22
initplus wrote: post #21

Earlier quoted context omitted.

http.ListenAndServe is implemented under the hood with a new goroutine per incoming connection. You don't have to explicitly use goroutines here, it's the default behaviour.

Yes _however_ the nodejs benchmark at least is handling each message asynchronously, whereas the go implementation is only handling connections asynchronously. The client fires off all the requests before waiting for a response: https://github.com/matttomasetti/NodeJS_Websocket-Benchmark-... so the comparison isn't quite apples to apples. Edit to add: looks like the same goes for the c++ and rust implementations. So…

Well, tcp streams are purely sequential. It’s the ideal use case for a single process, since messages can’t be received out of order. There’s no computational advantage to “handling each message asynchronously” unless the message handling code itself does IO or something. And that’s not the responsibility of the websocket library.

Re: An Analysis of the Performance of WebSockets in Various Programming Languages (2021)

#27

Post by josephg »

ndusart wrote: post #23
zo1 wrote: post #18

Was this published as-is to some sort of prominent CS journal? I honestly can't tell from the link. If that's the case, I'm very disappointed and would have a few choice words about the state of "academia".

Yes, that would be concerning indeed... The author couldn't tell why he didn't manage to make run the C or python program but figured it is probably the blame of the language for some obscure reasons. He also mentioned that he should have implemented multithreading in C++ to be comparable with Node, but meh that's probably also not of his concern, let compare them as is ^^` Also he doesn't mention the actual language…

Yeah it’s a rubbish paper. It’s just a comparison of some websocket implementations at some particular point in time. It tells you how fast some of the fastest WS implementations are in absolute terms, but there are no broad conclusions you can make other than the fact that there’s more room for optimisation in a few libraries. Whoopty doo. News at 11.
Post reply on HN