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

41–45 of 45 posts

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

#41

Post by austin-cheney »

klabb3 wrote: post #31
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…

> Their explanation for why Go performs badly didn't make any sense to me. To me, the whole paper is full of misunderstanding, at least the analysis. There's just speculation based on caricatures of the language, like "node is async", "c++ is low level" etc. The fact that their C++ impl using uWebSocket was significantly slower than then Node, which used uWebSocket bindings, should have led them to question the test…

There is no HTTP handshake in RFC6455. A client sends a text with a pseudo unique key. The server sends a text with a key transform back to the client. The client then opens a socket to the server.

The distinction is important because assuming HTTP implies WebSockets is a channel riding over an HTTP server. Neither the client or server cares if you provide any support for HTTP so long as the connection is achieved. This is easily provable.

It also seems you misunderstand the relationship between WebSockets and TLS. TLS is TCP layer 4 while WebSockets is TCP layers 5 and 6. As such WebSockets work the same way regardless of TLS but TLS does provide an extra step of message fragmentation.

There is a difference in interpreting how a thing works and building a thing that does work.

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

#42

Post by fastaguy88 »

A meta comment: This paper gives an example of a "teaser abstract". It says what was done, but does not say anything about the actual results. This style is relatively common, but I find it very annoying. There was certainly enough room in the abstract to provide a concise summary of the actual results, which would both inform the reader and perhaps encourage more people to read the entire paper.

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

#43

Post by aprilfoo »

timkofu wrote: post #37

It would be interesting to this repeated with Starlette and Granian on Python 13 (with GIL and JIT).

I had a quick run with Starlette/uvicorn: similar results than node/uws, a bit faster actually but not significant enough to be meaningful. So I would expect similar results with other modern/fast libraries. I also found that the "websockets" library is a bit slower (25% or so), all with the default settings of that benchmark.

The issue with Python that the author faced takes 2 minutes to identify and fix: raise ulimits.

Finally, one can question the value of such benchmark in real world applications, especially when the supporting article is so poorly researched as other already pointed.

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

#44

Post by klabb3 »

austin-cheney wrote: post #41
klabb3 wrote: post #31

Earlier quoted context omitted.

> Their explanation for why Go performs badly didn't make any sense to me. To me, the whole paper is full of misunderstanding, at least the analysis. There's just speculation based on caricatures of the language, like "node is async", "c++ is low level" etc. The fact that their C++ impl using uWebSocket was significantly slower than then Node, which used uWebSocket bindings, should have led them to question the test…

There is no HTTP handshake in RFC6455. A client sends a text with a pseudo unique key. The server sends a text with a key transform back to the client. The client then opens a socket to the server. The distinction is important because assuming HTTP implies WebSockets is a channel riding over an HTTP server. Neither the client or server cares if you provide any support for HTTP so long as the connection is achieved. T…

Call it what you will. The point about the handshake is that TCP + http headers need comes before the upgrade to use the raw tcp streams. This is part of the benchmark and while it exists also in the real world it can be misleading because that’s testing connections, not message throughput.

Also I was wrong about uWebSocket, they do have tls support so you can skip reverse proxy. It deals with raw tcp conns and thus to encrypt you need tls support there. It is also a barebones http/1.1 server because why not. The thing I misremembered is I confused tls with http/2 which it does not support. This is unrelated to WS.

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

#45

Post by tgv »

bryancoxwell wrote: post #36
tgv wrote: post #19

Earlier quoted context omitted.

> 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.

Are you referring to Go’s stdlib?

Yes, the repo uses encoding/json from the standard library.
Post reply on HN