تحقيق 8.8 جيجابت في الثانية لحركة الفيديو على نواة معالج واحدة بلغة Go

MicrosoftMicrosoft
يصف مطور من Habr بناء محرك بث مخصص من RTSP إلى HLS بلغة Go يُسمى Ruseon Core لمعالجة مشكلة قطيع الثيران (Thundering Herd). يستخدم المحرك مخزنًا دائريًا بنسخ صفري مع sync.Pool لتجنب تخصيص الذاكرة، محققًا إنتاجية تصل إلى 8.8 جيجابت في الثانية على نواة واحدة، مع استخدام ضئيل للذاكرة ووحدة المعالجة المركزية، على عكس FFmpeg أو MediaMTX.
بعد أن تسبب رابط مشترك في اندفاع هائل للخوادم وحدوث انقطاع في الذاكرة (OOM)، قرر المؤلف بناء محرك بث مخصص بلغة Go بدلاً من استئجار أجهزة أكثر قوة. المحرك، الذي أُطلق عليه اسم Ruseon Core، يقوم بمعالجة بثوط RTSP (Real-Time Streaming Protocol) وإخراج HLS (HTTP Live Streaming) دون تحويل الشيفرة (transcoding)، فقط تمرير البايتات. الميزة الأساسية هي مخزن مؤقت حلقي بدون نسخ (zero-copy) مع sync.Pool: حيث تُكتب الإطارات مرة واحدة في مخزن مؤقت من مجموعة (pool) وتُشارك مع جميع المشتركين، مما يلغي التخصيصات (allocations) وضغط مجموعة القمامة (GC). يُظهر الاختبار المعياري 13.9 نانوثانية لكل عملية و0 بايت لكل عملية. عند اختبار التحميل باستخدام k6 (1000 مستخدم) على معالج Ryzen 5600x، تم تحقيق 8.8 جيجابت في الثانية (81 جيجابايت في 70 ثانية) مع 60 ألف استجابة HTTP ناجحة دون أي فشل. حماية المشتركين تستخدم إرسالات عبر قنوات غير محظورة (non-blocking channel sends) مع إسقاط الإطارات للعملاء البطيئين، وعلم NeedsIFrame لإعادة المزامنة على الإطار الرئيسي التالي. يتم الاحتفاظ بنافذة منزلقة من 5 مقاطع HLS في الذاكرة؛ وإذا كانت المقاطع قديمة تُرجع 404، مما يدفع المشغلات مثل hls.js للانتقال إلى الحافة المباشرة. يستخدم النظام 250 ميغابايت من الذاكرة العشوائية (RAM) لـ 100 بث، لكن مخازن مقابس نظام التشغيل (OS socket buffers) تضيف عبئًا إضافيًا. ويحذر المؤلف من مزالق sync.Pool ويقترح أنه بالنسبة لأحمال العمل غير المتحولة، تجنب استخدام FFmpeg والتحكم في الذاكرة من خلال النسخ بدون نسخ (zero-copy) يكون مفيدًا.
المصدر: Habr — хаб ИИ — الأصلي
منشوراتنا السابقة حول هذا الموضوع ↓
أخبار جديدة