this post was submitted on 12 Aug 2024
90 points (95.9% liked)
Opensource
1433 readers
57 users here now
A community for discussion about open source software! Ask questions, share knowledge, share news, or post interesting stuff related to it!
⠀
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Wait, why would you not use a websocket for this?
My guess that websocket add additional overhead both in size (header) and complexity as browser and server need to encode/decode it making it more CPU intensive not to mention harder to implement.
I've implemented it myself, down to the encoding and buffer management.
It's a really simple back and forth first, but after that it's just dumping arbitrary binary data through the socket
Yes, but with WebSocket you need to have a server and that will consume some additional CPU.
Without it you only need some random CDN to do the download test.
This server is just a piece of software that accepts and responds to TCP sockets. It could be anything, but you're not consuming more CPU power by doing less work.
The http protocol requires you prepend every message with a bunch of headers and for them to have a static size. (tho plenty of apps allow you to bend the rules quite a bit)
After switching to a websocket, none of that applies. You can just dump data straight into the TCP socket. Or TLS stream that goes into the TCP socket. But that would be same for the http requests
On the server side to send you data, using any web server with mmap support will probably be less CPU intensive than app that handles websocket, but yes, the details matter as when reading a lot of small files vs websocket, then websocket could be better for CPU usage especially when you could generate data.
But once again using plain old http allow you to use the speestest software against any CDN very easy IMO.
Adding headers and some other minor requirements is slower than not. That's really the difference, it's not complicated.