Cómo Discord redujo el tráfico de WebSocket en un 40%

• Cuando el cliente se conecta a Discord, recibe actualizaciones en tiempo real sobre lo que está ocurriendo a través de un servicio llamado "Gateway"
• Desde finales de 2017, las conexiones del cliente al Gateway se comprimían usando zlib, lo que redujo el tamaño de los mensajes entre 2 y 10 veces
• Zstandard (zstd) ofrece una mayor tasa de compresión que zlib, tiempos de compresión más cortos y soporte para diccionarios, lo que puede reducir aún más el ancho de banda
• Aunque los resultados de las pruebas con zstd en 2019 no fueron muy positivos, concluyeron que valía la pena intentarlo de nuevo

Streaming con zstd

• Mientras que zlib usaba compresión en streaming, zstd no la usaba
• En cargas útiles pequeñas, zstd rendía peor que zlib
• Hicieron un fork de ezstd, el binding de zstd para Elixir, y le añadieron streaming
• Tras cambiar a zstd con streaming, lograron mejoras importantes frente a zlib streaming tanto en compresión como en velocidad

Esfuerzos de optimización

Ajuste fino

• Ajustaron parámetros de compresión de zstd como chainlog, hashlog y windowlog para equilibrar el uso de memoria y el tiempo de compresión

Diccionarios de zstd

• Intentaron aprovechar la función de diccionario de zstd para mejorar la tasa de compresión, pero el efecto fue limitado
• Consideraron que la complejidad de usar diccionarios era mayor que sus beneficios y decidieron no adoptarlos

Mejora de buffers

• Implementaron un ciclo de retroalimentación para ampliar los buffers de zstd usando la memoria sobrante en horas de baja actividad
• La tasa de mejora fue menor de lo esperado y, aunque intentaron optimizarla ajustando configuraciones del asignador de BEAM, retiraron la idea porque el beneficio no justificaba la complejidad

Implementación y despliegue

• Como la mejora de ancho de banda con zstd era grande, decidieron aplicarla no solo en móvil sino también en escritorio
• Encontraron bindings de zstd adecuados para cada plataforma, como Java, Objective-C y Rust, y lo desplegaron gradualmente durante varios meses

Logro adicional: Passive Sessions V2

• Durante la adopción de zstd descubrieron que los mensajes passive_update_v1 representaban más del 30% del ancho de banda del Gateway
• Introdujeron passive_update_v2, que envía solo los canales y miembros modificados, y redujeron ese uso de ancho de banda del 35% al 5%

Grandes ahorros

• La combinación de Passive Sessions v2 y zstd redujo casi un 40% el ancho de banda del Gateway usado por los clientes
• Haber encontrado una oportunidad de optimización no prevista demuestra la importancia de contar con la instrumentación adecuada y analizar las gráficas con una mirada crítica

[GN⁺]

Comentarios de Hacker News

• Hay quejas sobre que Discord tarda entre 20 y 30 segundos en iniciar

  • Se cuestiona por qué arranca tan lento incluso en una PC de $5000
  • Se usa la analogía de que parece que recompilan el cliente en un solo núcleo cada vez

• Parece que se enfocaron en la tasa de compresión y en reducir el ancho de banda de red

  • No se menciona el tiempo de CPU ni mejoras medibles para los usuarios reales
  • Cuando hicieron un esfuerzo similar en una empresa, el rendimiento empeoró por la sobrecarga de compresión/descompresión

• Resulta interesante el enfoque de compresión basado en diccionarios usando JSON y Erlang ETF

  • Eligieron ese enfoque en lugar de migrar a sistemas basados en esquemas como Cap'n Proto o Protobufs
  • Hay interés en benchmarks de Zstandard y LZ4
  • En el caso de datos de overlay/HUD en streaming para drones, usaron LZ4 y lograron una compresión similar a alta velocidad con un diccionario generado por la herramienta de diccionarios de Zstd

• Sorprende que la respuesta de bootstrap habitual (READY) supere los 2 MB

• Se menciona el contenido real del dispatch PASSIVE_UPDATE_V1

  • Incluso cuando solo cambia un elemento, se envían todos los canales, miembros o miembros de voz
  • Las métricas descubiertas durante el experimento con zstd muestran un comportamiento sorprendente
  • Se cuestiona por qué no analizaron las métricas desde el principio
  • Se cuestiona por qué no enviaron deltas desde el principio

• No se menciona si es seguro frente a ataques como los de oráculo de compresión (BREACH)

  • Dado que Discord invirtió mucho esfuerzo en el despliegue de la compresión, se asume que lo habrán considerado
  • Hay opiniones de que habría sido bueno escribir algo más específico al respecto

• Hay un problema en el que la computadora se pone lenta al abrir una pestaña de Discord

• Se valora mucho que explicaran las cosas que intentaron pero no funcionaron

  • Los artículos que describen intentos fallidos son cada vez más raros, pero resultan muy interesantes y útiles

• Opinión de que mIRC lo hacía mejor