VOD Benchmark آزمونی کنترل‌شده برای سنجش ظرفیت و کیفیت واقعی پخش ویدئوی درخواستی است. خروجی مفید آن باید روشن کند زیرساخت با چه ترکیبی از کاربران، کیفیت تصویر، وضعیت کش و شرایط شبکه، معیارهای محصول را رعایت می‌کند. تعداد درخواست موفق یا حداکثر پهنای باند، به‌تنهایی اثبات‌کننده پخش پایدار نیست.
برای مدیر محصول، پرسش اصلی زمان شروع و تداوم تماشا است؛ برای CTO، ظرفیت قابل اتکا، گلوگاه، رفتار هنگام خرابی و هزینه اهمیت دارد. این راهنما چارچوب مشترکی برای طراحی آزمون، مقایسه پیشنهادها و پذیرش زیرساخت ارائه می‌کند. اعداد نمونه در این مقاله فرضی‌اند و نتیجه آزمون آوابرید یا هیچ ارائه‌دهنده دیگری نیستند.
VOD Benchmark چه چیزی را باید اثبات کند؟
پیش از اجرا، ادعای قابل آزمون بنویسید: «سامانه باید بار هدف را در ترکیب مشخص دستگاه و اپراتور، با زمان شروع و نرخ خطای توافق‌شده تحمل کند.» کنار این ادعا، محدوده مسئولیت را مشخص کنید: آیا فقط Origin آزموده می‌شود یا مسیر کامل احراز مجوز، CDN، Player و دریافت مجوز DRM نیز در محدوده است؟
در VOD Benchmark سه سطح را جدا گزارش کنید: کارایی اجزای زیرساخت، ظرفیت مسیر تحویل و تجربه واقعی کاربر. آزمون دیسک یا HTTP برای یافتن محدودیت اجزا مفید است؛ اما رفتار Decode، بافر، انتخاب کیفیت و خطاهای Player را کامل بازسازی نمی‌کند. برای شناخت اجزای مسیر، راهنمای معماری زیرساخت VOD و پخش پایدار ویدئو را ببینید.
دو نوع مقایسه نیز پاسخ متفاوتی دارند: در «منابع برابر»، مقدار CPU، حافظه، ظرفیت شبکه و سیاست کش را همسان می‌کنید؛ در «بودجه برابر»، کل هزینه قابل مقایسه را ثابت می‌گیرید. نتیجه این دو آزمایش را در یک رتبه‌بندی مبهم ادغام نکنید.
معیارهای اصلی VOD Benchmark: ظرفیت، Latency و کیفیت تجربه
هر شاخص باید نقطه شروع، نقطه پایان، مخرج و جامعه آماری روشن داشته باشد. در ویدئوی درخواستی، Latency معمولاً به تأخیر درخواست، شروع پخش یا Seek اشاره می‌کند؛ تأخیر دوربین تا نمایشگر که در پخش زنده مطرح است، معیار اصلی این ارزیابی نیست.
| شاخص | تعریف عملیاتی | کاربرد در تصمیم |
|---|---|---|
| کاربران هم‌زمان فعال | نشست‌هایی که واقعاً در حال دریافت یا پخش رسانه‌اند؛ با کاربران واردشده یکسان نیست | تعیین ظرفیت قابل سرویس |
| زمان شروع پخش | از اقدام معتبر کاربر برای پخش تا نمایش نخستین فریم؛ تبلیغ یا DRM را صریحاً در دامنه تعریف کنید | پذیرش تجربه ورود به تماشا |
| TTFB و زمان دریافت Segment | زمان تا نخستین بایت، جدا از مدت دریافت کامل پاسخ | تفکیک تأخیر پاسخ از محدودیت انتقال |
| نرخ شکست شروع | تعداد تلاش‌های ناموفق برای شروع تقسیم بر همه تلاش‌های واجد شرایط | کشف خطاهایی که میانگین زمان شروع پنهان می‌کند |
| نسبت بافر مجدد | در این راهنما: زمان توقف ناشی از کمبود بافر تقسیم بر مجموع زمان پخش و همان توقف‌ها، پس از شروع | سنجش تداوم تماشا؛ توقف دستی و تأخیر شروع جدا هستند |
| کیفیت تحویلی | توزیع کیفیت یا Bitrate همراه با تغییر کیفیت و فریم‌های ازدست‌رفته | تشخیص کاهش کیفیت برای پنهان‌کردن فشار |
| زمان بازیابی خدمت | از وقوع اختلال تا بازگشت معیارهای توافق‌شده برای یک بازه پایدار | ارزیابی رفتار عملیاتی هنگام خرابی |
چرا میانگین تأخیر کافی نیست؟
میانگین ممکن است تجربه نامناسب بخشی از کاربران را پنهان کند. در گزارش VOD Benchmark، p50، p95 و در صورت کافی‌بودن نمونه p99 را همراه با تعداد نمونه ثبت کنید. p95 برابر دو ثانیه یعنی حدود ۹۵ درصد مشاهدات معتبر آن جامعه، تأخیری حداکثر در همین محدوده داشته‌اند؛ این عدد تضمین همه کاربران نیست.
صدک‌ها را به تفکیک اپراتور، منطقه، دستگاه و وضعیت کش بخوانید. میانگین‌گرفتن از p95 چند سرور، p95 کل سامانه را تولید نمی‌کند؛ برای تجمیع به نمونه‌ها یا توزیع‌های قابل ادغام نیاز دارید. شکست‌ها و Timeoutها را نیز جدا گزارش کنید تا حذف آن‌ها از محاسبه زمان پاسخ، نتیجه را خوش‌بینانه نکند.
ظرفیت قابل‌قبول چگونه تعریف می‌شود؟
ظرفیت قابل‌قبول، بیشترین باری است که تمام معیارهای پذیرش را در مدت و سناریوی مشخص رعایت می‌کند. عددی که فقط چند ثانیه پیش از اشباع ثبت شده، ظرفیت عملیاتی نیست. ظرفیت بهره‌برداری را با حاشیه‌ای متناسب با رشد، عدم قطعیت و سناریوی خرابی انتخاب کنید؛ یک درصد ثابت برای همه معماری‌ها معتبر نیست.
طراحی بار واقعی برای VOD Benchmark
پروفایل بار را از رفتار مخاطب بسازید: طول نشست، نسبت ورودهای جدید، کیفیت‌های مصرف‌شده، محبوبیت عناوین، سهم Seek، زیرنویس و صوت جداگانه، جغرافیا و دستگاه. درخواست مکرر یک فایل محبوب، معمولاً وضعیت کش گرم را می‌سنجد و نماینده کل کتابخانه نیست.
برای یک برآورد ساده، ترافیک تحویل برحسب گیگابیت‌برثانیه تقریباً برابر است با تعداد بینندگان هم‌زمان ضرب‌در میانگین Bitrate تحویلی برحسب مگابیت‌برثانیه، تقسیم بر هزار. مثلاً ۳۰۰۰ بیننده با میانگین مجموع صوت و تصویر ۴ مگابیت‌برثانیه، حدود ۱۲ گیگابیت‌برثانیه بار رسانه ایجاد می‌کنند؛ سربار پروتکل و حاشیه ظرفیت جدا هستند.
در همین مثال، اگر صوت و تصویر جدا و Segmentها شش‌ثانیه‌ای باشند، تخمین پایه درخواست رسانه حدود ۱۰۰۰ درخواست در ثانیه است: ۳۰۰۰ ضرب‌در دو، تقسیم بر شش. Manifest، مجوز، آغاز پخش، Retry و Seek به این عدد اضافه می‌شوند. این مدل یکنواخت است؛ Player واقعی ممکن است دانلودهای پشت‌سرهم یا پیش‌دریافت داشته باشد. برای مبانی بیشتر، محاسبه Bitrate و پهنای باند استریم ویدئو و محاسبه ظرفیت کاربران هم‌زمان در VOD مکمل این بخش‌اند.
مدل باز و بسته را با هدف آزمون انتخاب کنید
در مدل بسته، شروع تکرار بعدی به پایان تکرار فعلی وابسته است؛ کندشدن سامانه می‌تواند نرخ ایجاد بار را هم کاهش دهد. مدل باز، ورود تکرارها را مستقل از پایان قبلی زمان‌بندی می‌کند و برای سنجش نرخ ورود مشخص مناسب است. مستندات مدل باز و بسته در k6 این تفاوت را توضیح می‌دهد.
در VOD Benchmark هیچ‌کدام همیشه برتر نیست: نشست تماشا به زمان‌بندی رسانه نیاز دارد، اما هجوم شروع پخش ممکن است با نرخ ورود مستقل مدل شود. تعداد VU در ابزار را بدون تعریف سناریو، معادل تعداد بیننده نگیرید. بار هدف، بار واقعاً ایجادشده و تکرارهای اجرا‌نشده را کنار هم ثبت کنید.
| سناریو | روش طراحی | شواهد لازم |
|---|---|---|
| Baseline | بار کم با محتوای معتبر و تنظیم ثابت | خط مبنای تأخیر و صحت پخش |
| افزایش پله‌ای | افزایش بار و مکث کافی در هر پله | نقطه نقض SLO و روند صف‌ها |
| هجوم ورود | شروع هم‌زمان تعداد زیادی نشست | زمان شروع، فشار مجوز و Origin |
| کش سرد | مجموعه آزمون جدید یا نسخه‌های تأییدشده خارج از کش | Miss واقعی، ترافیک Origin و زمان گرم‌شدن |
| آزمون ماندگاری | بار طولانی متناسب با نشست‌ها و چرخه‌های عملیاتی | رشد حافظه، اتصال، خطا و تأخیر |
| اختلال کنترل‌شده | خروج یک جزء و اجرای مسیر بازیابی | اثر بر نشست‌ها و زمان بازگشت کیفیت |
روش اجرای VOD Benchmark؛ از آماده‌سازی تا گزارش
۱. قرارداد آزمون و معیار توقف را بنویسید
دامنه، منابع، نسخه نرم‌افزار، زمان اجرا، محدودیت هزینه و سقف بار را ثبت کنید. آزمون بار و اختلال باید روی منابع مجاز و با هماهنگی مالک سرویس اجرا شود. آستانه توقف را بر پایه خطا، اشباع یا اثر بر کاربران تعیین کنید و مسئول توقف و بازگشت را مشخص کنید.
برای هر معیار یک هدف از پیش توافق‌شده داشته باشید. برای نمونه، «p95 شروع کمتر از ۲٫۵ ثانیه در شبکه و دستگاه تعریف‌شده» می‌تواند شرط یک آزمایش باشد؛ این عدد استاندارد عمومی VOD نیست. در k6 می‌توان قواعد قبولی و رد را با Thresholdها ثبت کرد. موفقیت یک Check به‌تنهایی جای معیار پذیرش کل آزمون را نمی‌گیرد.
۲. محتوا و مسیر پخش را پیش از بارگذاری اعتبارسنجی کنید
Manifest، Segment، فایل Initialization، صوت و زیرنویس باید سالم و در دسترس باشند. پاسخ HTTP موفق برای اثبات قابل‌پخش‌بودن فایل کافی نیست. ابزارهای اعتبارسنجی معرفی‌شده در مستندات رسمی HLS اپل و آزمون Player روی دستگاه هدف، به تشخیص خطاهای بسته‌بندی کمک می‌کنند.
مجموعه محتوای VOD Benchmark باید نماینده اندازه فایل، Codec، کیفیت و الگوی محبوبیت واقعی باشد. نسخه مجموعه و Checksum دارایی‌های آزمون را نگه دارید تا تغییر محتوا با تغییر زیرساخت اشتباه نشود. مسیر مجوز و DRM را در آزمون انتهابه‌انتها فعال نگه دارید یا حذف آن را صریحاً در محدودیت گزارش بنویسید.
۳. ابزار بارساز را از ابزار سنجش تجربه جدا کنید
بارسازهایی مانند k6 برای درخواست‌های HTTP و سناریوهای برنامه‌ریزی‌شده مفیدند، اما اسکریپت HTTP ساده موتور پخش ویدئو نیست. در کنار بار پروتکلی، گروهی از Playerهای واقعی یا خودکارشده را برای ثبت نخستین فریم، بافر، انتخاب کیفیت و Seek به کار بگیرید. اندازه این گروه باید برای ادعایی که مطرح می‌کنید کافی باشد.
ظرفیت ماشین‌های بارساز را نیز پایش کنید: CPU، شبکه، اتصال و نرخ تولید بار. اگر بار هدف ساخته نشده یا تولیدکننده اشباع شده باشد، نتیجه VOD Benchmark سقف توان سامانه مقصد را اثبات نمی‌کند. محل بارساز نیز مهم است؛ آزمایش از داخل همان دیتاسنتر، تجربه مسیر اینترنت کاربر را نشان نمی‌دهد.
۴. اندازه‌گیری را هم‌زمان و قابل تکرار انجام دهید
زمان سامانه‌ها را هماهنگ و برای هر اجرا شناسه مستقل تعیین کنید. داده Player، CDN، Origin و Storage را در بازه‌های یکسان بررسی کنید. مدت گرم‌کردن، پنجره اندازه‌گیری و زمان تخلیه نشست‌ها را جدا ثبت کنید. در گزارش VOD Benchmark، فقط بهترین اجرا را انتخاب نکنید؛ تکرارها، دامنه تغییرات و علت کنارگذاشتن هر اجرای نامعتبر را نشان دهید.
برای مقایسه A و B، ترتیب اجرا را جابه‌جا کنید یا اجراها را در شرایط مشابه تکرار کنید تا ساعت پرترافیک یا تغییر مسیر شبکه نتیجه را منحرف نکند. پیش از هر تغییر، نسخه تنظیمات را نگه دارید و در هر مقایسه تا حد امکان یک عامل اصلی را عوض کنید.
پایداری در VOD Benchmark؛ کش سرد، Failover و آزمون طولانی
کش گرم بخشی از تصویر است. انتشار عنوان جدید، تغییر CDN یا خروج یک نقطه تحویل می‌تواند الگوی مراجعه به Origin را تغییر دهد. سیاست Cache Key و TTL روی نتیجه اثر می‌گذارد؛ مستندات کش و دسترس‌پذیری CloudFront نمونه‌ای از وابستگی رفتار کش به تنظیمات ارائه‌دهنده است.
در VOD Benchmark، وضعیت سرد و گرم را با مشاهده Hit/Miss و ترافیک بالادست تأیید کنید. افزودن یک Query تصادفی الزاماً کش را دور نمی‌زند؛ ممکن است آن پارامتر در Cache Key نباشد. از پاک‌کردن کش تولید فقط برای ایجاد سناریو خودداری کنید و از مجموعه آزمون کنترل‌شده استفاده کنید.
برای Failover، هم شروع نشست جدید و هم ادامه نشست جاری را بسنجید. موفقیت انتقال درخواست به مقصد دوم کافی نیست؛ Token، مسیر فایل، CORS، Range Request و نسخه محتوا باید با Player سازگار باشند. زمان تشخیص خرابی، تصمیم مسیریابی، گرم‌شدن مقصد و بازگشت کیفیت را جدا ثبت کنید.
در آزمون طولانی، روندها مهم‌تر از یک اسکرین‌شات سالم‌اند. رشد پیوسته حافظه، انباشت اتصال، افزایش صف یا تشدید تأخیر خواندن ممکن است پس از چند ساعت آشکار شود. مدت آزمون را با طول نشست، تمدید مجوز و چرخه‌های عملیاتی انتخاب کنید. یک تست کوتاه، اثبات‌کننده SLA ماهانه یا پایداری دائمی نیست.
نمونه فرضی مقایسه دو معماری با VOD Benchmark
جدول زیر صرفاً نمونه آموزشی با اعداد ساختگی است. فرض می‌کنیم هر دو معماری با محتوای یکسان، بار ۳۰۰۰ بیننده، شبکه‌ها و دستگاه‌های یکسان و پنجره اندازه‌گیری ثابت آزموده شده‌اند. اهداف پذیرش نیز فقط برای همین مثال تعریف شده‌اند.
| معیار و شرط نمونه | معماری A | معماری B | برداشت |
|---|---|---|---|
| p95 شروع؛ حداکثر ۲٫۵ ثانیه | ۲٫۱ ثانیه | ۲٫۴ ثانیه | هر دو در این معیار قبول |
| شکست شروع؛ حداکثر ۰٫۵٪ | ۰٫۳٪ | ۰٫۴٪ | تعداد تلاش‌ها و تکرارها باید همراه گزارش باشد |
| نسبت بافر؛ حداکثر ۱٪ با مخرج تعریف‌شده | ۱٫۴٪ | ۰٫۷٪ | A با وجود شروع سریع‌تر رد می‌شود |
| بازیابی پس از اختلال تعریف‌شده؛ حداکثر ۶۰ ثانیه | ۸۵ ثانیه | ۴۵ ثانیه | فقط B شرط این سناریو را رعایت می‌کند |
| شاخص هزینه برای همین بار؛ مبنا ۱۰۰ | ۱۰۰ | ۱۱۲ | B گران‌تر است؛ هزینه باید کنار کیفیت تفسیر شود |
نتیجه نمونه این نیست که B همیشه بهتر است؛ فقط در شرایط تعریف‌شده، A معیار بافر و بازیابی را رعایت نمی‌کند. گزارش VOD Benchmark باید این محدودیت را حفظ کند. اگر هدف محصول تغییر کند یا ترکیب مخاطبان متفاوت باشد، مقایسه باید دوباره اجرا شود.
برای ارزیابی اقتصادی، هزینه محاسبات، ذخیره‌سازی، درخواست، خروج داده، CDN و عملیات را در یک بازه یکسان جمع کنید. سپس آن را بر ساعات تماشایی تقسیم کنید که معیار کیفیت تعریف‌شده را گذرانده‌اند. «هزینه هر ساعت تماشای قابل‌قبول» می‌تواند از قیمت هر گیگابایت به تصمیم محصول نزدیک‌تر باشد؛ تعریف ساعت قابل‌قبول باید در هر دو گزینه ثابت بماند.
چک‌لیست پذیرش و گزارش مدیریتی VOD Benchmark
- هدف، دامنه، نسخه‌ها، منابع و جامعه مخاطب آزمون ثبت شده‌اند.
- محتوا و مسیر مجوز پیش از ایجاد بار اعتبارسنجی شده‌اند.
- بار هدف با بار واقعاً تولیدشده و نشست‌های فعال تطبیق داده شده است.
- تأخیر درخواست از زمان شروع و کیفیت پخش جدا گزارش شده است.
- صدک‌ها، تعداد نمونه، خطاها و Timeoutها قابل مشاهده‌اند.
- کش سرد، کش گرم، ورود ناگهانی و آزمون طولانی پوشش داده شده‌اند.
- Failover با پخش واقعی و وضعیت نشست جاری بررسی شده است.
- معیار قبولی، سقف آزموده‌شده و حاشیه ظرفیت با هم اشتباه نشده‌اند.
- هزینه و محدودیت‌های مقایسه در گزارش آمده‌اند.
- اسکریپت، تنظیمات، زمان اجرا و خروجی خام برای بازتولید نگهداری می‌شوند.
صفحه اول گزارش VOD Benchmark را به تصمیم اختصاص دهید: ظرفیت تأییدشده در شرایط آزمون، معیارهای ردشده، گلوگاه اصلی، هزینه و اقدام بعدی. جزئیات فنی و داده خام در پیوست باشند. برای نمونه، تصمیم می‌تواند «پذیرش مشروط به اصلاح مسیر کش سرد و تکرار آزمون» باشد؛ نتیجه الزاماً قبول یا رد مطلق کل معماری نیست.
پرسش‌های متداول درباره VOD Benchmark
آیا تست سرعت دانلود برای ارزیابی VOD کافی است؟
خیر. دانلود یک فایل، نرخ ورود نشست، مجوز، تغییر کیفیت، بافر و Seek را کامل پوشش نمی‌دهد. در VOD Benchmark باید کارایی انتقال را کنار پخش واقعی و سناریوهای خرابی سنجید.
برای اثبات ظرفیت چند بار آزمون را تکرار کنیم؟
عدد ثابتی برای همه پروژه‌ها وجود ندارد. تعداد تکرار و حجم نمونه به نوسان شبکه، دقت موردنیاز و شدت تصمیم وابسته است. به‌جای انتخاب بهترین نتیجه، پراکندگی اجراها و شرایط هر اجرا را ارائه کنید.
آیا پاسخ ۲۰۰ به معنی موفقیت پخش است؟
خیر. فایل ممکن است ناقص، ناسازگار یا دیررس باشد و Player نتواند آن را پخش کند. اعتبار رسانه، رویداد نخستین فریم و تداوم پخش باید جدا بررسی شوند؛ پاسخ ۲۰۶ نیز در درخواست‌های Range می‌تواند کاملاً معتبر باشد.
آیا VOD Benchmark جای پایش کاربران واقعی را می‌گیرد؟
خیر. آزمون کنترل‌شده برای مقایسه و کشف محدودیت مفید است؛ پایش کاربران واقعی، تنوع شبکه و دستگاه در بهره‌برداری را آشکار می‌کند. داده عملیاتی باید پروفایل آزمون بعدی را اصلاح کند.
ارزش VOD Benchmark در پیوند دادن یک ادعای ظرفیت به شواهد قابل تکرار است. زمانی می‌توان درباره توسعه یا خرید زیرساخت تصمیم گرفت که کیفیت پخش، رفتار هنگام اختلال و هزینه، هم‌زمان و تحت شرایط روشن سنجیده شده باشند.