Como o Discord reduziu o tráfego de WebSocket em 40%

• Quando o cliente se conecta ao Discord, ele recebe atualizações em tempo real sobre o que está acontecendo por meio de um serviço chamado "Gateway"
• Desde o fim de 2017, as conexões do cliente ao Gateway são comprimidas com zlib, reduzindo o tamanho das mensagens de 2 a 10 vezes
• Zstandard (zstd) oferece taxa de compressão maior que o zlib, menor tempo de compressão e suporte a dicionários, o que pode reduzir ainda mais a largura de banda
• Os resultados dos testes com zstd em 2019 não foram muito positivos, mas a equipe concluiu que valia a pena tentar novamente

Streaming com zstd

• Enquanto o zlib usava compressão em streaming, o zstd não usava
• Em cargas pequenas, o zstd teve desempenho pior que o zlib
• A equipe fez um fork do ezstd, binding de zstd para Elixir, e adicionou suporte a streaming
• Depois de migrar para streaming com zstd, houve uma grande melhora em taxa de compressão e velocidade em relação ao streaming com zlib

Esforços de otimização

Ajustes finos

• Parâmetros de compressão do zstd, como chainlog, hashlog e windowlog, foram ajustados para equilibrar uso de memória e tempo de compressão

Dicionário do zstd

• A equipe tentou aproveitar o recurso de dicionário do zstd para melhorar a taxa de compressão, mas o efeito foi limitado
• Concluiu-se que a complexidade de usar dicionários era maior que os benefícios, então a ideia não foi adotada

Upgrade de buffer

• Foi implementado um ciclo de feedback para fazer upgrade dos buffers do zstd usando memória ociosa nos horários de menor uso
• A taxa de upgrade foi menor que o esperado; tentativas de melhorar isso, como ajustar configurações do alocador do BEAM, não trouxeram benefícios suficientes para justificar a complexidade, e a iniciativa foi revertida

Implementação e lançamento

• Como o ganho de largura de banda com zstd foi grande, decidiu-se aplicá-lo não só no mobile, mas também no desktop
• Bindings de zstd adequados para cada plataforma, como Java, Objective-C e Rust, foram encontrados e lançados gradualmente ao longo de vários meses

Resultado adicional: Passive Sessions V2

• Durante a adoção do zstd, foi descoberto que a mensagem passive_update_v1 representava mais de 30% da largura de banda do Gateway
• Com a introdução de passive_update_v2, que envia apenas canais e membros alterados, esse uso de largura de banda caiu de 35% para 5%

Grande economia

• A combinação de Passive Sessions v2 com zstd reduziu em quase 40% a largura de banda de Gateway usada pelos clientes
• A descoberta de uma oportunidade de otimização não intencional mostra a importância de analisar gráficos com a instrumentação adequada e uma visão crítica

[GN⁺]

Comentários do Hacker News

• Há reclamações sobre o tempo de inicialização do Discord, que leva 20–30 segundos

  • Questionam por que a inicialização é lenta até mesmo em um PC de US$ 5000
  • Usam a analogia de que parece que recompilam o cliente inteiro em um único núcleo toda vez

• Parece que o foco foi na taxa de compressão e na redução da largura de banda de rede

  • Não há menção ao tempo de CPU nem a melhorias mensuráveis para usuários reais
  • Quando fizeram um esforço parecido na empresa, o desempenho piorou por causa do overhead de compressão/descompressão

• A abordagem de compressão baseada em dicionário usando JSON e Erlang ETF é interessante

  • Foi a escolha feita em vez de migrar para um sistema baseado em esquema como Cap'n Proto ou Protobufs
  • Há interesse em benchmarks de Zstandard e LZ4
  • No caso de dados de overlay/HUD de streaming de drones, usaram LZ4 e conseguiram compressão semelhante em alta velocidade com um dicionário gerado pela ferramenta de dicionário do Zstd

• É surpreendente que uma resposta típica de bootstrap (READY) tenha mais de 2 MB

• Há menção ao conteúdo real do dispatch PASSIVE_UPDATE_V1

  • Mesmo quando apenas um único elemento mudou, ele envia todos os canais, membros ou membros de voz
  • As métricas descobertas durante o experimento com zstd mostram um comportamento surpreendente
  • Questionam por que não fizeram análise de métricas desde o início
  • Questionam por que não enviaram deltas desde o começo

• Não há menção à segurança contra ataques como oráculos de compressão (BREACH)

  • Como o Discord dedicou muito esforço ao rollout da compressão, acreditam que isso deve ter sido considerado
  • Acham que teria sido bom escrever de forma mais específica sobre isso

• Há um problema em que abrir uma aba do Discord deixa o computador lento

• Foi muito bom explicarem coisas que tentaram, mas não funcionaram

  • Artigos que explicam tentativas fracassadas estão cada vez mais raros, mas isso é muito interessante e útil

• Opinião de que o mIRC fazia isso melhor