Discord Reduced WebSocket Traffic by 40%(discord.com) |
Discord Reduced WebSocket Traffic by 40%(discord.com) |
How dare you belittle the new Super Ultra Nitro Deluxe Gold Platinum emoji, stickers, and playable sound effects.
Are there any benefits/features to using their Electron desktop app?
Also would be interested in benchmarks between Zstandard vs. LZ4 for this use case - for a very different use case (streaming overlay/HUD data for drones), I ended up using LZ4 with dictionaries produced by the Zstd dictionary tool. LZ4 produced similar compression at substantially higher speed, at least on the old ARM-with-NEON processor I was targeting.
I guess it's not totally wild but it's a bit surprising that common bootstrapping responses (READY) were 2+MB, as well.
Protos or a custom wire protocol would be far better suited to the task.
IIRC it’s used in the desktop client and some community libraries (specifically JDA) have support for it.
There were some quirks regarding ETF usage with Discord’s Gateway but I can’t recall at the moment.
> the metrics that guided us during the [zstd experiment] revealed a surprising behavior
This feels so backwards. I'm glad that they addressed this low-hanging fruit, but I wonder why they didn't do this metrics analysis from the start, instead of during the zstd experiment.
I also wonder why they didn't just send deltas from the get-go. If PASSIVE_UPDATE_V1 was initially implemented "as a means to scale Discord servers to hundreds of thousands of users", why was this obvious optimization missed?
[1]: https://en.wikipedia.org/wiki/Oracle_attack [2]: https://en.wikipedia.org/wiki/BREACH
2024-09-20T13:28:42.946055-07:00 hostname kernel: audit: type=1400 audit(1726864122.944:11828880): apparmor="DENIED" operation="ptrace" class="ptrace" profile="snap.discord.discord" pid=1055465 comm="Utils" requested_mask="read" denied_mask="read" peer="unconfined"
And my computer isn't particularly crazy. Maybe like $1500.
But on a more serious note, I still hate bloated software. Money can't buy latency and the sluggishness gets really annoying.
Most of the time I have seen people complain about this it is because they have joined a ton of hyperactive servers.
You could argue it shouldn't be an issue and more dynamically load things like messages on servers. But then you'd have people complaining that switching servers takes so long.
Yes.
>Also relevant, do you need to be in all of them?
Yes.
You must be new here, because if you aren't connected to dozens of servers and idling in hundreds of channels (you only speak in maybe two or three of them) you aren't IRCing right.
What? I'm a confused old clod because we're talking about Discord in the year of our lord 2024? Same thing, it's a massive textual chat network based on a server-channel hub-spoke architecture at its core.
What is actually worth our time asking is why we could do all that and more with no problems in the 80s and 90s using hardware a thousandth or less as powerful as what we have today.
> the compression time per byte of data is significantly lower for zstandard streaming than zlib, with zlib taking around 100 microseconds per byte and zstandard taking 45 microseconds
Either way the incremental improvements here are great - and it's important to consider optimization both from transport level (compression, encoding) and also from a protocol level (the messages actually sent over the wire.)
Also one thing not mentioned is client side decompression on desktop used to use a JS implementation of zlib (pako) to a native implementation, that's exposed to the client via napi bindings.
But we don't use any of the usual cloud offerings, only smaller local companies.
Time to compress is a measure of how long the CPU spends compressing. So this is in the blogpost
Client-side compute may sound like a contrived issue, but Discord runs on a wide variety of devices. Many of these devices are not necessarily the latest flagship smartphones, or a computer with a recent CPU.
I am going to guess that zstd decompression is roughly as expensive as zlib, since (de)compression time was a motivating factor in the development of zstd. Also the reason to prefer zstd over xz, despite the latter providing better compression efficiency.
> Looking once again at MESSAGE_CREATE, the compression time per byte of data is significantly lower for zstandard streaming than zlib, with zlib taking around 100 microseconds per byte and zstandard taking 45 microseconds.
I was surprised to see little server-side CPU benchmarking too, though. While I'd expect overall client timing for (transfer + decompress) to be improved dramatically unless the user was on a ridiculously fast network connection, I can't imagine server load not being affected in a meaningful way.
I use either option in different circumstances, they're both comparably fine.
You clearly have issues with that unpolished turd. So I figured I'd offer my insights in what often causes that.
If you still insist on having your computer coming to a crawl because IRC did it better than that's entirely up to you.
in reality on IRC almost every client connected with invisible mode on so aggregating big vinn diagrams of overlapping channels between users in every channel was a lot more laborious.
Custom protocol would be binary.
They could make a custom extension but it wouldn’t be that easy.
I worked on browser devtools for IE and edge.
Even chrome/vscode use jsonrpc over websockets for ease of development.
The start of a tcp connection is limited by round trip times more than bandwidth. Especially for mobile, optimizing to reduce the number of round trips required is pretty handy.
* You can't share your screen in a way optimized for text clarity. In the native app, even without nitro, you, effectively, have the "source resolution, 5 fps" option. With the web app, you are limited to 720p.
* You can't make the full use of your camera. On the web, 640x480 is the only available resolution, while in the native app, 1280x720 is the default.
* Also, on platforms other than Linux, with the native app, you can stream the game audio separately from your microphone. This functionality is not available via the web or on Linux unless you install an unofficial client.
https://gregoryszorc.com/blog/2017/03/07/better-compression-...
though I always thought lz4 to be the sweet spot for anything requiring speed, somewhat less compression ratio in exchange for very fast compression and decompression
To a second approximation it gets more complicated. Atoms can save you some repetition of what would otherwise be strings, because they are effectively interned strings and get passed as tagged integers under the hood, but it's fairly redundant to what compression would get you anyhow, and erlang term representations of things like dictionaries can be quite rough:
3> dict:from_list([{a, 1}, {b, 2}]).
{dict,2,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
{{[],
[[a|1]],
[[b|2]],
[],[],[],[],[],[],[],[],[],[],[],[],[]}}}
Plus, even if you're stuck to JSON one of the first things you do is shorten all your keys to the point they're as efficient as tagged integers on the wire anyhow ("double-quote x double-quote" can even beat an integer, that's only 3 bytes). Doesn't take a genius to note that "the_message_after_it_has_been_formatted_by_the_markdown_processor" can be tightened up a bit if bandwidth is tight.
It isn't clearly a loss over JSON but it is certainly not a clear win either. If you're converting from naive Erlang terms to some communication protocol encoding you're already paying for a total conversion and you might as well choose from the full set of option at that point.
Does this change anything w.r.t your response?
In my case, ultimately, paranoia has won. :)
How much do you really trust discord? Or games on steam, or slack, or zoom client?
Flatpak does provide you, out of the box, with a sandbox for whole discord app. Sandbox is built on standard linux stuff like bubblewrap / seccomp / namespaces. This should prevent discord from, for example, accessing anything other than ~/Downloads (rw), ~/Pictures (ro) and so on. Or seeing what other processess are running on my pc. Or snooping in my ~/.ssh.
Some stuff might not work out of box and will require reading app's README or wiki. I imagine stuff like "john is listening to song - artist" would require additional permission or configuration. File sharing could be complicated if, for example, discord could not access my screenshots directory. Webcam, voice and screen sharing work out of box but are protected by "portals" provided by (in my case) KDE.
Discord, for example, does not pollute my /usr or /home. It stays somewhere in /var/lib/flatpak/ and keeps my user files in ~/.var/app/$APPNAME. Steam, Slack, all other "big proprietary apps" also keep their stuff in ~/.var/app/$APPNAME. It's not really a choice for them; flatpak just mounts proper directories in proper places and it works really well.
You can use `nsenter --target $PID --pid --net --mount --ipc` and look around to what kind of access flatpak apps have to your system.
Sorry about preaching, I just like that bit of additional separation from stuff I don't really want to trust or care about.
Take a few minutes to learn how it works then. Flatpak doesn't replace apt, which is a system package manager. Flatpak is for standalone apps, like Discord.
Flatpak provides basic level of sandboxing that ensures non-malicious stupid stuff like how steam had a bug to delete the entire user directory doesn’t actually impact you.
Beyond that, discord probably won’t solve issues with the N package managers if something happens. They’re a lot more likely to solve a Flatpak problem though.
It's an ongoing battle
(I run a relatively small Discord community so I'm sincerely curious how people engage with servers and discover new stuff in it)
Also how much can you realistically win when the payload for small messages where the difference matters are text?
Moving to a binary format would be better for 99.9% of users and would be a slight inconvenience to a few people creating bots. Discord could easily publish a library for reading the format if needed.
Electron is great for developers because it allows them to easily build a cross platform app. Businesses love it for this reason.
Most users don't care. They barely realize what software is to begin with, and the mere suggestion that things could be different is baffling to them.
Then you have the highly technical users who know the software could be better, but isn't, because of the previous points.
You can recognize them because they dislike the feel without even knowing what's an electron app. I can vouch they're not insecure about Electron.
There is a unique type of jank associated with it.
Would love to live in the apparently "bizzaro" world where desktop class apps developed using tools which try to be more native to the OS were still successful in 2024.
Every update to Adobe creative suite makes it more and more close to an electron app and further and further away from it's roots as one of the premiere high end desktop caliber programs. I interpret the rise of Electron to be mostly correlated with the lack of knowledge on how to do old school desktop GUI development among the folks who teach CS education.
I expect that fl studio, photoshop, word, and every other remaining good desktop caliber app will be lost to the "make everything a in web-browser" trend, eventually. I'm so over it and it hasn't happened yet.
This is also the reason why GenAI STILL has no good prosumer tools. ComfyUI/Automatic1111/Forge/lm-studio are the closest we have and they're gradio or electron webapps which indicates that AI folks are not down with leaving the python or JS ecosystem for even a minute.
This means we need good desktop caliber GUI developers who understand AI. Unfortunately, they basically don't exist.
Thus, the world runs SOTA models on janky shit gradio or electron frontends instead of the desktop GUI's we had for similar UIs 10-20 years ago.
Word 2003 was peak software, and I'll never change my mind.
Different apps have different unique quirks/odd behaviour, almost none of them do the right thing on platforms like macOS.
There must be a better way.
For announcement channels that I'm feeling more certain I don't want to miss: I created a server for myself with a channel that has subscriptions to all the announcement channels that I want to be notified about (I also check this manually, but at least it is a custom-tailored feed just for me).
There is no coping with the (..checks Discord..) "4k+" outstanding notifications (and counting) that I am bombarded with. Slightly ironic that the Discord interface can't even be bothered to tell me the exact count; I'm not going to bother.
It used to amuse me to see people complain about @everyone tags. The commonality of it leaves me desensitized these days.
Much of this is just grumbling. I love Debian, hate Ubuntu, and think things shouldn’t change a lot.
Still, looking at those benchmarks, 10MB/s sounds like the absolute minimum reasonable speed, and they’re reporting nearly three orders of magnitude below that. A modern compressor does not run at mediocre dialup speeds; something in there is absolutely murdering the performance.
And I’m willing to believe it’s just the constant-time overhead. The article mentions “a few hundred bytes” per message payload in a stream of messages, and the actual data of the benchmarks implies 1.6KB uncompressed. Even though they don’t reinitialize the compressor on each message, that is still a very very modest amount of data.
So it might be that general-purpose compressors are simply a bad tool here from a performance standpoint. I’m not aware of a good tool for this kind of application, though.
A payload of 1.6KB at 45us/B is 75ms, which is below the typical scheduling quantum of about 100ms. (Can’t say anything about Erlang, let alone Erlang bindings to C libraries, but I wouldn’t expect it to be that much smaller either, precisely because of the switching overhead both direct and indirect.) So a single compression operation shouldn’t be getting preempted enough to affect the results.
Typical RAM bandwidth is tens of GB/s (even consumer-class SSDs[1] are single-digit GB/s) so with tens to hundreds of cores that’s not enough to affect anything, and even taking into account the compressor’s window is measured in megabytes not kilobytes that’s likely not enough (it would be a bad compressor that reread its whole window each time, anyway). And the data we’re compressing is not only minuscule, it has just been generated and is virtually guaranteed to be cached.
Honestly, I almost want to say that the benchmark is measuring the wrong thing somehow, except they’re reporting a 2× speedup switching from one compressor to another. So it can’t be the JSON encoding overhead or whatnot, and, unless one of the Erlang bindings is somehow drastically stupider than the other, it shouldn’t be the FFI overhead, and even those are a huge stretch. The Flying Spaghetti Monster be merciful, I cannot see anything here that we could be spending over a hundred million cycles on.
At this point I’m hoping somebody just mixed up the units, because this is really unsettling.
Second, I noticed we're extrapolating from a tossed out measurement in "microseconds per byte" here, of extremely small payloads, probably included fixed-cost overhead of doing anything at all.
All leading up to: Is "atrocious" the right word choice here? :)
More directly: do you really think Discord rolled out a compression algorithm that does 23 KB/s for payloads in the megabytes?
Even more directly, avoiding being passive and just adopting your tone: this is atrocious analysis that glibly chooses to create obviously wrong numbers, then criticizes them as if they are real.
yes, actually