Discord Reduced WebSocket Traffic by 40%
Discord reduced websocket traffic by 40% by implementing zstandard compression, improving performance and bandwidth usage, especially on mobile, after adding streaming support and optimizing compression settings.
Read original articleDiscord has successfully reduced its websocket traffic by 40% through the implementation of zstandard compression, which replaced the previously used zlib. The transition aimed to enhance performance and reduce bandwidth usage, particularly on mobile platforms. Initially, zstandard did not perform as expected compared to zlib, primarily due to the lack of streaming compression capabilities. However, after forking the ezstd library to add streaming support, zstandard's performance improved significantly, achieving better compression ratios and faster compression times. The team also experimented with various compression settings and explored the use of dictionaries to optimize compression further. While the dictionary approach showed mixed results, the overall enhancements from zstandard streaming led to a notable reduction in payload sizes. Additionally, Discord investigated upgrading zstandard buffers during off-peak hours to utilize excess memory, although this strategy yielded less impact than anticipated due to memory fragmentation issues. Ultimately, the combination of these strategies has led to a more efficient and responsive service for users.
- Discord reduced websocket traffic by 40% using zstandard compression.
- Initial tests showed zstandard underperformed compared to zlib until streaming support was added.
- Compression settings were fine-tuned to optimize performance.
- Dictionary support was explored but ultimately deemed too complex for significant gains.
- Upgrading zstandard buffers during off-peak hours was less effective than expected due to memory fragmentation.
Related
Latest update for 'fast' compression algorithm LZ4 sprints past old versions
The LZ4 compression algorithm version 1.10 has been released, featuring significant performance improvements, multithreading support, and faster decompression speeds, benefiting various Linux applications and enhancing the zswap feature.
Ziglang.org migrates from AWS to self-hosting
The Zig Software Foundation migrated from AWS to a self-hosted solution using a €36 Hetzner server to reduce costs, improve deployment speed, and encourage community involvement for resilience.
Compression Dictionary Transport
The draft-ietf-httpbis-compression-dictionary-19 proposes a dictionary-based compression mechanism for HTTP, enhancing performance and reducing bandwidth, with guidelines for usage and negotiation, currently under evaluation for standardization.
SQLite Transparent Compression
The sqlite-zstd extension for SQLite offers up to 80% database size reduction through row-level compression, supports multiple programming languages, and includes detailed installation instructions, with caution advised for production use.
Dave: Discord's New End-to-End Encryption for Audio and Video
Discord has launched DAVE, an end-to-end encryption protocol for audio and video calls, ensuring only participants access content, with dynamic keys and open-source design for enhanced user privacy.
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.
> 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
Related
Latest update for 'fast' compression algorithm LZ4 sprints past old versions
The LZ4 compression algorithm version 1.10 has been released, featuring significant performance improvements, multithreading support, and faster decompression speeds, benefiting various Linux applications and enhancing the zswap feature.
Ziglang.org migrates from AWS to self-hosting
The Zig Software Foundation migrated from AWS to a self-hosted solution using a €36 Hetzner server to reduce costs, improve deployment speed, and encourage community involvement for resilience.
Compression Dictionary Transport
The draft-ietf-httpbis-compression-dictionary-19 proposes a dictionary-based compression mechanism for HTTP, enhancing performance and reducing bandwidth, with guidelines for usage and negotiation, currently under evaluation for standardization.
SQLite Transparent Compression
The sqlite-zstd extension for SQLite offers up to 80% database size reduction through row-level compression, supports multiple programming languages, and includes detailed installation instructions, with caution advised for production use.
Dave: Discord's New End-to-End Encryption for Audio and Video
Discord has launched DAVE, an end-to-end encryption protocol for audio and video calls, ensuring only participants access content, with dynamic keys and open-source design for enhanced user privacy.