Comment Discord a réduit de 40 % le trafic WebSocket

• Lorsqu’un client se connecte à Discord, il reçoit des mises à jour en temps réel sur ce qui se passe via un service appelé « passerelle »
• Depuis fin 2017, les connexions des clients à la passerelle sont compressées avec zlib, ce qui a réduit la taille des messages d’un facteur de 2 à 10
• Zstandard (zstd) offre un meilleur taux de compression que zlib, des temps de compression plus courts et prend en charge les dictionnaires, ce qui peut encore réduire la bande passante
• Les résultats des tests zstd en 2019 n’étaient pas très positifs, mais l’équipe a estimé que cela valait la peine de réessayer

Streaming avec zstd

• zlib utilisait la compression en streaming, tandis que zstd ne l’utilisait pas
• Sur les petites charges utiles, zstd était moins performant que zlib
• L’équipe a forké ezstd, le binding zstd pour Elixir, afin d’y ajouter le streaming
• Le passage au streaming zstd a apporté de nettes améliorations, tant en taux de compression qu’en vitesse, par rapport au streaming zlib

Efforts d’optimisation

Réglages

• Ajustement des paramètres de compression zstd comme chainlog, hashlog et windowlog afin d’équilibrer l’utilisation mémoire et le temps de compression

Dictionnaires zstd

• L’équipe a essayé d’améliorer le taux de compression en exploitant la fonctionnalité de dictionnaire de zstd, mais l’effet est resté limité
• La complexité liée à l’usage des dictionnaires a été jugée supérieure aux bénéfices, et leur adoption a donc été abandonnée

Mise à niveau des buffers

• Mise en place d’une boucle de rétroaction pour augmenter les buffers zstd en utilisant la mémoire excédentaire pendant les heures creuses
• Le taux de mise à niveau a été plus faible que prévu, et malgré des tentatives d’amélioration, notamment via des ajustements des paramètres de l’allocateur BEAM, les bénéfices n’ont pas justifié la complexité, donc l’idée a été retirée

Implémentation et déploiement

• Les gains de bande passante apportés par zstd étant importants, l’équipe a décidé de l’appliquer non seulement au mobile, mais aussi au desktop
• Des bindings zstd adaptés à chaque plateforme, comme Java, Objective-C et Rust, ont été trouvés, puis déployés progressivement sur plusieurs mois

Résultat supplémentaire : Passive Sessions V2

• Au cours de l’adoption de zstd, l’équipe a découvert que les messages passive_update_v1 représentaient plus de 30 % de la bande passante de la passerelle
• L’introduction de passive_update_v2, qui n’envoie que les canaux et membres modifiés, a fait passer cette part de bande passante de 35 % à 5 %

Importantes économies

• La combinaison de Passive Sessions v2 et de zstd a réduit de près de 40 % la bande passante de passerelle utilisée par les clients
• La découverte d’une opportunité d’optimisation inattendue montre l’importance d’une instrumentation adaptée et d’une analyse critique des graphiques

[GN⁺]

Avis sur Hacker News

• Certains se plaignent que Discord mette 20 à 30 secondes à se lancer

  • On se demande pourquoi le démarrage est lent même sur un PC à 50 $
  • L’un d’eux compare cela au fait de recompiler le client sur un seul cœur à chaque fois

• L’article semble s’être concentré sur le taux de compression et la réduction de la bande passante réseau

  • Il n’y a aucune mention du temps CPU ni d’améliorations réellement mesurables pour les utilisateurs
  • Dans une entreprise, des efforts similaires ont abouti à de moins bonnes performances à cause du surcoût de compression/décompression

• L’approche de compression fondée sur des dictionnaires avec JSON et Erlang ETF est jugée intéressante

  • C’est la voie choisie au lieu de passer à des systèmes basés sur des schémas comme Cap'n Proto ou Protobufs
  • Certains aimeraient voir des benchmarks entre Zstandard et LZ4
  • Pour les données d’overlay/HUD en streaming de drones, LZ4 a été utilisé, avec un dictionnaire généré par l’outil de dictionnaire de Zstd pour obtenir une compression similaire à haute vitesse

• Il est surprenant qu’une réponse de bootstrap classique (READY) dépasse 2 Mo

• Des commentaires portent sur le contenu réel du dispatch PASSIVE_UPDATE_V1

  • Même lorsqu’un seul élément change, tous les canaux, membres ou membres vocaux sont renvoyés
  • Les métriques découvertes pendant les expérimentations avec zstd ont révélé un comportement surprenant
  • Certains se demandent pourquoi l’analyse des métriques n’a pas été faite dès le départ
  • D’autres se demandent pourquoi des deltas n’ont pas été envoyés dès le début

• Il n’y a aucune mention de la résistance à des attaques comme les attaques par oracle de compression (BREACH)

  • Étant donné les efforts importants investis par Discord dans le déploiement de la compression, on suppose que cela a été pris en compte
  • Certains auraient aimé des explications plus concrètes à ce sujet

• Ouvrir un onglet Discord ralentirait l’ordinateur

• Beaucoup apprécient que l’article explique aussi ce qui a été tenté sans fonctionner

  • Les articles qui décrivent des tentatives ratées se font de plus en plus rares, alors que c’est très intéressant et utile

• Selon un avis, mIRC faisait mieux