Hardware & InferenzOpen Source 🇷🇺 07.08.2026 13:02

8,8 Gbit/s Video-Traffic auf einem einzelnen CPU-Kern in Go erreichen

MicrosoftMicrosoft
Ein Entwickler von Habr beschreibt den Bau einer eigenen RTSP-zu-HLS-Streaming-Engine in Go namens Ruseon Core, um das Thundering-Herd-Problem zu lösen. Die Engine verwendet einen Zero-Copy-Ringpuffer mit sync.Pool, um Speicherzuweisungen zu vermeiden, und erreicht einen Durchsatz von 8,8 Gbit/s auf einem einzelnen Kern bei minimalem Speicher- und CPU-Verbrauch, anders als FFmpeg oder MediaMTX.
Nachdem ein geteilter Link eine Herde von Anfragen (Thundering Herd) und einen Server-OOM verursacht hatte, entschied sich der Autor, eine eigene Streaming-Engine in Go zu entwickeln, anstatt leistungsfähigere Hardware zu mieten. Die Engine, genannt Ruseon Core, nimmt RTSP-Streams auf und gibt HLS ohne Transkodierung aus, indem sie nur Bytes weiterleitet. Das Herzstück ist ein Zero-Copy-Ringpuffer mit sync.Pool: Frames werden einmal in einen Puffer aus dem Pool geschrieben und mit allen Abonnenten geteilt, wodurch Allokationen und GC-Druck eliminiert werden. Benchmark zeigt 13,9 ns/op und 0 B/op. Lasttests mit k6 (1000 Benutzer) auf einem Ryzen 5600x erreichten 8,8 Gbit/s (81 GB in 70 Sekunden) mit 60.000 erfolgreichen HTTP-Antworten und keinen Fehlern. Der Abonnentenschutz verwendet nicht-blockierende Kanal-Sends mit Verwerfen von Frames für langsame Clients sowie ein NeedsIFrame-Flag, um beim nächsten Keyframe neu zu synchronisieren. Ein gleitendes Fenster von 5 HLS-Segmenten wird im Speicher gehalten; veraltete Segmente geben 404 zurück, wodurch Player wie hls.js zur Live-Kante springen. Das System verwendet 250 MB RAM für 100 Streams, aber die Socket-Puffer des Betriebssystems fügen Overhead hinzu. Der Autor warnt vor Fallstricken von sync.Pool und empfiehlt, für nicht transkodierende Workloads auf FFmpeg zu verzichten und die Speicherkontrolle mit Zero-Copy zu nutzen.
Quelle: Habr — хаб ИИ — Original
Unsere früheren Beiträge zu diesem Thema ↓
Aktuelle Nachrichten