Alcançando 8,8 Gbps de Tráfego de Vídeo em um Único Núcleo de CPU em Go
Microsoft
Um desenvolvedor do Habr descreve a construção de um mecanismo de streaming personalizado de RTSP para HLS em Go, chamado Ruseon Core, para lidar com o problema do Thundering Herd (rebanho em disparada). O mecanismo utiliza um buffer circular de cópia zero com sync.Pool para evitar alocações, alcançando uma taxa de transferência de 8,8 Gbps em um único núcleo, com uso mínimo de memória e CPU, ao contrário do FFmpeg ou MediaMTX.
Depois que um link compartilhado causou uma enxurrada de requisições e estouro de memória no servidor, o autor decidiu construir um motor de streaming personalizado em Go em vez de alugar hardware mais potente. O motor, chamado Ruseon Core, ingere fluxos RTSP e emite HLS sem transcodificação, apenas retransmitindo bytes. A principal característica é um buffer circular de zero cópia com sync.Pool: os quadros são escritos uma vez em um buffer proveniente do pool e compartilhados com todos os assinantes, eliminando alocações e pressão no coletor de lixo. O benchmark mostra 13,9 ns/operação e 0 B/operação. Testes de carga com k6 (1000 usuários) em um Ryzen 5600x alcançaram 8,8 Gbps (81 GB em 70 segundos) com 60 mil respostas HTTP bem-sucedidas e nenhuma falha. A proteção dos assinantes usa envios não bloqueantes em canais, com descarte de quadros para clientes lentos, e uma flag NeedsIFrame para ressincronizar no próximo quadro-chave. Uma janela deslizante de 5 segmentos HLS é mantida na memória; segmentos obsoletos retornam 404, fazendo com que players como o hls.js saltem para a borda ao vivo. O sistema usa 250 MB de RAM para 100 fluxos, mas os buffers de soquete do sistema operacional adicionam sobrecarga. O autor alerta sobre armadilhas do sync.Pool e sugere que, para cargas de trabalho sem transcodificação, evitar o FFmpeg e controlar a memória com zero cópia é benéfico.
Fonte: Habr — хаб ИИ —
original