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

11–20 of 45 posts

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

#12

Post by simpaticoder »

Interesting that https://github.com/uNetworking/uWebSockets.js (which is C++ with node bindings) outperforms the raw C++ uWebSockets implementation.

It's also interesting that https://github.com/websockets/ws does not appear in this study, given that in the node ecosystem it is ~3x more likely to be used (not a perfect measurement but ws has 28k github stars vs uWebSockets 8k stars)

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

#15

Post by ikornaselur »

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…

Yeah I thought this looked familiar.. I went through this article about a year and a half ago when exploring WebSockets in Python for work. With some tuning and using a different libraries + libuv we were easily able to get similar performance to NodeJS.

I had a blog post somewhere to show the testing and results, but can't seem to find it at the moment though.

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

#16

Post by donjoe »

windlep wrote: post #8
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.

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

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

#17

Post by nelsonic »

travisgriggs wrote: post #5

Thanks for the free access links. I did read through a bit. The title is misleading because exactly one implementation was chosen for each of the tested languages. They conclude “do not us e Python” because the Python websockets library performs pretty poorly. Each language is scored based on the library chosen. I have to believe there are more options for some of these languages. As someone who is implementing an El…

Was also surprised they omitted Elixir/Erlang from the list of languages. Crazy considering how many messaging apps use OTP on the backend.

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

#19

Post by tgv »

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…

> I'm curious how much of this is really measuring JSON [de]serialization performance.

Well, they did use the standard library for that, so quite a bit, I suppose. That thing is slow. I've got no idea how fast those functions are in other languages, but you're right that it would ruin the idea behind the benchmark.

Post reply on HN