ظرفیت همزمان VOD تعداد نشستهای پخشی است که سامانه میتواند در یک بازه مشخص، با کیفیت تجربه قابل قبول پشتیبانی کند. این عدد با تعداد کاربران ثبتنامشده، بازدید روزانه یا تعداد اتصالهای TCP یکسان نیست. برای CTO و مدیر زیرساخت، سؤال اصلی این است: با ترکیب کیفیتهای فعلی، وضعیت کش و منابع موجود، چند کاربر میتوانند بدون افزایش نامطلوب زمان شروع یا توقف پخش ویدئو تماشا کنند؟
در این راهنما، محاسبه ظرفیت کاربران همزمان در VOD را از تخمین تقاضا تا پهنای باند، بار Origin، تعداد درخواستها و آزمون خرابی دنبال میکنیم. تمام اعداد مثالها فرضیاند و باید با اندازهگیری روی سرویس واقعی جایگزین شوند. برای شناخت ارتباط لایهها، ابتدا راهنمای جامع معماری زیرساخت VOD و پخش پایدار ویدئو را ببینید.
۱. تعریف ظرفیت همزمان VOD و معیار پذیرش
پیش از خرید منابع، تعریف «کاربر فعال» را مشخص کنید: نشست در حال پخش، نشست در حال دریافت داده، یا پخشکنندهای که اخیراً Heartbeat فرستاده است؟ یک Player ممکن است پس از پرکردن بافر برای مدتی دانلود نکند؛ بنابراین اتصال فعال شبکه، شمارنده دقیقی برای بینندگان نیست. همچنین چند دستگاه متعلق به یک حساب، چند نشست پخش ایجاد میکنند.
برای محاسبه ظرفیت همزمان VOD، نشستهای پخش را با شناسه یکتا و پنجره زمانی مشخص بشمارید. نشستهای متوقفشده یا رهاشده باید پس از مهلت تعریفشده از شمارش خارج شوند. تعریف این پنجره و نحوه برخورد با Pause را کنار هر گزارش بنویسید.
ظرفیت پذیرفتهشده باید به SLO متصل باشد: زمان شروع پخش، نرخ خطای شروع، نسبت زمان Rebuffering و کیفیت دریافتی کاربران. آستانهها را برای محصول خود تعیین کنید؛ کاهش اجباری کیفیت همه کاربران ممکن است عدد همزمانی را بالا ببرد، اما الزاماً به معنی موفقیت ظرفیتسنجی نیست.
۲. تخمین تقاضا برای ظرفیت همزمان VOD
در یک بازه نسبتاً پایدار، تعداد متوسط نشستهای همزمان را میتوان از حاصلضرب نرخ ورود نشستها در متوسط مدت حضور آنها تخمین زد:
Average concurrent sessions ≈ Session starts per second × Average session duration (seconds)
اگر در هر ثانیه ۵ نشست شروع شود و متوسط مدت هر نشست ۱۲۰۰ ثانیه باشد، میانگین همزمانی حدود ۶۰۰۰ نشست است. این رابطه، تخمین متوسط در شرایط پایدار است؛ ظرفیت پیک کمپین، انتشار قسمت جدید یا ورود ناگهانی کاربران را تضمین نمیکند.
دادههای دقیقهای زمان شروع، طول نشست، منطقه، اپراتور و نوع دستگاه را بررسی کنید. پیک همزمانی و پیک شروع پخش را جدا نگه دارید؛ دو سرویس با ۱۰ هزار بیننده ممکن است به دلیل تفاوت تعداد شروعهای همزمان، فشار کاملاً متفاوتی روی احراز هویت و سرور مجوز DRM داشته باشند.
۳. بیتریت مؤثر در ظرفیت همزمان VOD
در پخش تطبیقی، همه کاربران بالاترین کیفیت را دریافت نمیکنند. بیتریت مؤثر باید میانگین وزندار کیفیتهای واقعاً تحویلشده باشد؛ نه میانگین ساده نردبان کیفیت و نه فقط رزولوشن ویدئو. صدای انتخابشده نیز باید در محاسبه حضور داشته باشد.
b_avg = Σ (share_i × bitrate_i) Σ share_i = 1
نمونه زیر یک توزیع فرضی است. بیتریت هر ردیف، مجموع صوت و تصویر را شامل میشود و واحد همه ردیفها Mbps است.
| کیفیت | سهم نشستها | بیت ریت مجموع | سهم در میانگین |
|---|---|---|---|
| کیفیت پایین | ۲۰٪ | ۱٫۲ | ۰٫۲۴ |
| کیفیت متوسط | ۵۰٪ | ۳ | ۱٫۵ |
| کیفیت بالا | ۳۰٪ | ۶ | ۱٫۸ |
| جمع | ۱۰۰٪ | — | ۳٫۵۴ Mbps |
این میانگین برای تخمین مصرف پایدار مناسب است. در مستندات HLS اپل، بیتریت متوسط و بیتریت پیک قطعات مفاهیم جداگانهای هستند. دانلود قطعات معمولاً پیوسته و با نرخ ثابت رخ نمیدهد؛ Player ممکن است یک قطعه چندثانیهای را سریع دریافت کند و سپس منتظر بماند. بنابراین برای ظرفیت همزمان VOD، پیکهای کوتاهمدت را نیز از لاگ و آزمون استخراج کنید.
۴. فرمول پهنای باند و حاشیه ظرفیت
اگر N تعداد نشستها، b میانگین بیتریت بر حسب Mbps، k ضریب سربار و دانلود اضافی، و u سهم قابل استفاده از ظرفیت باشد، پهنای باند مورد نیاز از رابطه زیر تخمین زده میشود:
B_required (Gbps) = N × b × k / (1000 × u) N_bandwidth = floor(B_available × ۱۰۰۰ × u / (b × k))
ضریب k را با توجه به مرز اندازهگیری تعریف کنید: سربار انتقال، Retry و داده دانلودشده اما تماشانشده میتوانند روی آن اثر بگذارند. اگر بیتریت را از حجم واقعی خروجی شبکه محاسبه کردهاید، همان سربار را دوباره اضافه نکنید. پارامتر u نیز برای باقیگذاشتن حاشیه عملیاتی است و مقدار ثابت و جهانی ندارد.
مثال محاسبه برای ۱۰ هزار نشست
با N برابر ۱۰٬۰۰۰، بیتریت ۳٫۵۴ Mbps، ضریب فرضی ۱٫۱۰ و استفاده هدف ۷۰٪، ظرفیت برنامهریزیشده حدود ۵۵٫۶۳ Gbps میشود. مصرف پایه رسانه ۳۵٫۴ Gbps و مصرف با ضریب k برابر ۳۸٫۹۴ Gbps است. اختلاف این عدد با ۵۵٫۶۳، حاشیه ظرفیت انتخابشده را نشان میدهد.
برعکس، اگر مسیر قابل اتکای تحویل واقعاً ۱۰ Gbps ظرفیت داشته باشد، همین فرضها سقف برنامهریزی پهنای باند را حدود ۱۷۹۷ نشست نشان میدهند. این عدد فقط محدودیت شبکه است؛ CPU، ذخیرهسازی، سقف قرارداد یا QoE ممکن است زودتر مانع شوند. سرعت اسمی کارت شبکه را با پهنای باند تضمینشده اینترنت یکسان نگیرید.
۵. تفکیک ظرفیت CDN و Origin
با حضور CDN، عمده داده کاربران میتواند از لبه تحویل شود؛ در نتیجه پهنای باند خروجی به بینندگان با پهنای باند مورد نیاز Origin برابر نیست. برای تخمین ترافیک Origin از نسبت برخورد کش بر حسب بایت استفاده کنید، نه صرفاً درصد درخواستهای Hit.
Origin media throughput ≈ Viewer media throughput × (۱ − Byte hit ratio)
در مثال قبل، اگر خروجی رسانه ۳۵٫۴ Gbps و نسبت برخورد بایتی مؤثر ۹۵٪ باشد، بار پایه رسانه روی Origin حدود ۱٫۷۷ Gbps است. با ضریب فرضی ۱٫۱۰ و استفاده هدف ۷۰٪ در همین مسیر، ظرفیت برنامهریزی حدود ۲٫۷۸ Gbps میشود. این تخمین هزینه Manifest پویا، خطا، پرکردن چند کش مستقل یا سایر ترافیکها را جداگانه نیاز دارد.
نسبت مؤثر را در مرز Origin و برای بازه و نوع محتوای یکسان اندازه بگیرید. قابلیتهای تجمیع درخواست و کش میانی میتوانند رابطه درخواستهای لبه و Origin را تغییر دهند. درصد Hit گزارششده یک CDN لزوماً همان نسبت بایتی مورد نیاز این فرمول نیست.
کش سرد و تغییر مسیر ترافیک
اگر نسبت برخورد بایتی از ۹۵٪ به ۷۰٪ افت کند، بار پایه Origin در همین مثال از ۱٫۷۷ به ۱۰٫۶۲ Gbps میرسد؛ یعنی شش برابر. اگر هیچ دادهای از کش پاسخ نگیرد، مدل ساده تا ۳۵٫۴ Gbps بار پایه Origin پیش میرود. انتشار محتوای جدید، پاکسازی کش، تغییر Cache Key و جابهجایی به CDN دوم باید در آزمون دیده شوند.
مستندات CloudFront توضیح میدهد که تغییرات غیرضروری در کلید کش میتواند نسخههای تکراری از یک شیء ایجاد کند و درخواستهای Origin را افزایش دهد. توکن دسترسی را بدون طراحی اعتبارسنجی حذف نکنید؛ افزایش Hit نباید به تحویل محتوای مجاز یک کاربر به کاربر دیگر منجر شود.
۶. اثر تعداد درخواستها بر ظرفیت همزمان VOD
ظرفیت همزمان VOD فقط مسئله انتقال بایت نیست. اگر هر نشست یک ترک ویدئو و یک ترک صوت جداگانه دریافت کند، با مدت قطعه d ثانیه و t ترک فعال، نرخ پایه درخواست قطعات را میتوان چنین تخمین زد:
Segment RPS ≈ Concurrent sessions × Active separate tracks / Segment duration
برای ۱۰ هزار نشست، دو ترک و قطعات ۶ثانیهای، نرخ پایه حدود ۳۳۳۳ درخواست در ثانیه است. با قطعات ۲ثانیهای، این عدد به حدود ۱۰ هزار میرسد. این مدل برای دریافت عادی قطعات کامل است؛ بستهبندی صوت و تصویر در یک قطعه، درخواست Range یا تحویل قطعات جزئی رفتار متفاوتی ایجاد میکند.
درخواست Manifest، زیرنویس، Seek، Retry، تلهمتری، Token و DRM را جدا اضافه کنید. الگوی تازهسازی Manifest در VOD ایستا با پخش زنده یکسان نیست. همچنین RPS متوسط برای موج شروع پخش کافی نیست؛ بافر اولیه میتواند چند درخواست نزدیک به هم ایجاد کند.
۷. نقش CPU و ذخیرهسازی در ظرفیت همزمان VOD
در معماری ازپیشپردازششده، معمولاً به ازای هر بیننده Encoder جدا اجرا نمیشود. ظرفیت Transcoding با نرخ ورود محتوا، پروفایلهای خروجی و زمان مجاز آمادهسازی ارتباط دارد. در مقابل، بستهبندی لحظهای، رمزنگاری یا شخصیسازی میتوانند در مسیر درخواست هزینه پردازشی ایجاد کنند.
توان خواندن ذخیرهسازی، تأخیر، تعداد عملیات، اندازه قطعات و رفتار کش سیستمعامل را در کنار CPU و RAM بسنجید. تست خواندن ترتیبی یک فایل بزرگ نماینده بار هزاران فایل ویدیویی پراکنده نیست. برای لایه API، صف و دیتابیس نیز از اصول کانفیگ سرور اختصاصی برای اپلیکیشن و دیتابیس استفاده کنید.
برای هر مؤلفه، سقف آزمودهشده را به تعداد نشست قابل پشتیبانی در همان سناریو تبدیل کنید. کمترین این سقفها محدودکننده است؛ نمیتوان عدد Gbps شبکه را مستقیماً با RPS API مقایسه کرد. افزایش سرور Origin وقتی گلوگاه سرویس صدور مجوز است، مشکل را حل نمیکند.
۸. آزمون عملی ظرفیت همزمان VOD
آزمون معتبر باید رفتار Player را تقلید کند: خواندن Manifest، انتخاب کیفیت، دریافت قطعات با زمانبندی، تغییر کیفیت و Seek. صرفاً دانلود مکرر یک فایل محبوب با کش گرم معمولاً تصویری خوشبینانه از ظرفیت همزمان VOD میدهد.
- خط مبنا: یک نشست واقعی را روی دستگاه و شبکه هدف اندازه بگیرید و صحت محتوا، صوت و زیرنویس را بررسی کنید.
- افزایش مرحلهای: همزمانی را بالا ببرید و در هر پله تا پایدارشدن متریکها ادامه دهید؛ اولین عبور پایدار از SLO را ثبت کنید.
- موج ورود: نرخ شروع نشست را مستقل از کل همزمانی افزایش دهید و مسیر Token، DRM و بافر اولیه را بسنجید.
- تنوع محتوا: عناوین محبوب و کمبازدید، ویدئوهای کوتاه و بلند، کیفیتهای مختلف و کش سرد را ترکیب کنید.
- خرابی کنترلشده: خروج یک نود، کندی Storage و تغییر مسیر CDN را در محیط مجاز و با برنامه بازگشت آزمایش کنید.
- تست طولانی: نشت حافظه، انباشت اتصال و صف، انقضای توکن و افت تدریجی عملکرد را بررسی کنید.
تولیدکننده بار هم ممکن است محدود شود. CPU، شبکه و خطای سمت ابزار آزمون را ثبت کنید و در صورت نیاز از چند مولد مستقل استفاده کنید. آزمون روی CDN و سرویسهای بیرونی باید با هماهنگی ارائهدهنده و در محدوده مجاز انجام شود.
چه متریکهایی ثبت شوند؟
- Player: زمان شروع، خطای شروع، نسبت Rebuffering، کیفیت انتخابشده و شکست Seek؛
- CDN: بایت خروجی، RPS، وضعیت پاسخ و Hit بر حسب درخواست و بایت؛
- Origin: توان خروجی، تأخیر پاسخ در صدکهای بالا، خطای ۵xx و اتصالهای فعال؛
- زیرساخت: CPU، حافظه، تأخیر دیسک، صف I/O و محدودیت شبکه؛
- کنترل پخش: تأخیر و نرخ خطای احراز هویت، مجوز DRM و سرویس Session.
برای تکمیل پایش زیرساخت، راهنمای امنیت و مانیتورینگ سرور اختصاصی را ببینید. سلامت سرور را همراه با تجربه واقعی Player تفسیر کنید؛ CPU پایین بهتنهایی نشانه پخش سالم نیست.
۹. ظرفیت در خرابی و برنامه رشد
ظرفیت همزمان VOD در شرایط عادی و زمان خرابی را جدا اعلام کنید. اگر سه نود یکسان دارید و باید خروج یکی را تحمل کنید، بار هدف باید با ظرفیت آزمودهشده دو نود باقیمانده سازگار باشد. این مدل ساده فرض میکند توزیع بار مناسب است و Storage یا شبکه مشترک گلوگاه نشدهاند.
زمان راهاندازی نود جدید، گرمشدن کش و آمادهشدن سرویس را در برنامه Autoscaling لحاظ کنید. حاشیهای که برای نوسان بار گذاشتهاید الزاماً برای تحمل خرابی کافی نیست. برای هر منطقه و CDN نیز سقف قرارداد و توان تحویل عملی را مشخص کنید؛ جمع اسمی ظرفیتها تضمین توزیع صحیح ترافیک نیست.
۱۰. تفاوت ظرفیت لحظهای با حجم ترافیک
پهنای باند با حجم ماهانه فرق دارد. برای ساعتهای تماشای یک بازه، حجم پایه رسانه با واحد دهدهی تقریباً چنین محاسبه میشود:
Traffic (GB) ≈ Watch hours × Average bitrate (Mbps) × ۰.۴۵
یک ساعت تماشا با میانگین ۳٫۵۴ Mbps حدود ۱٫۵۹۳ GB داده رسانه دارد؛ ۱۰ هزار نفر با یک ساعت تماشای کامل، حدود ۱۵٫۹۳ TB مصرف پایه ایجاد میکنند. سربار و دانلود اضافی باید با همان تعریف قبلی جدا منظور شوند. صورتحساب ممکن است واحد یا روش محاسبه متفاوتی داشته باشد.
ظرفیت ذخیرهسازی کتابخانه نیز مستقل است: طول کل محتوا، مجموع بیتریت نسخههای نگهداریشده، فایل اصلی، نسخههای پشتیبان و سیاست نگهداری تعیینکنندهاند. تعداد بینندگان بهتنهایی اندازه دیسک لازم را مشخص نمیکند.
اشتباهات رایج در محاسبه ظرفیت همزمان VOD
- تبدیل کاربران روزانه به کاربران همزمان بدون داده مدت نشست؛
- نادیدهگرفتن صوت یا شمردن دوباره سربار شبکه؛
- استفاده از درصد Hit درخواست به جای نسبت Hit بایتی؛
- تعمیم آزمون یک فایل با کش گرم به کل کتابخانه؛
- فرض ظرفیت نامحدود API، DRM یا تولیدکننده بار؛
- محاسبه فقط حالت سالم و حذف سناریوی خرابی یا تغییر CDN؛
- افزایش همزمانی از طریق افت کیفیت، بدون گزارش اثر آن روی کاربر.
سؤالات متداول
یک سرور ۱۰ گیگابیتی چند کاربر VOD را پشتیبانی میکند؟
عدد ثابتی ندارد. با فرضهای مثال، سقف برنامهریزی شبکه حدود ۱۷۹۷ نشست است؛ اما با CDN، بار سرور تابع Missها خواهد بود. تنها آزمون ترکیب واقعی کیفیت، فایل و درخواست میتواند ظرفیت عملی را تعیین کند.
آیا CDN ظرفیت همزمان VOD را نامحدود میکند؟
خیر. سقف تحویل و قرارداد CDN، بار Origin هنگام Miss، سرویسهای کنترل پخش و محدودیت شبکه کاربران باقی میمانند. ظرفیت باید برای هر مسیر و وضعیت خرابی سنجیده شود.
آیا کوتاهکردن قطعات همیشه بهتر است؟
خیر. با کوتاهشدن قطعات، تعداد درخواستها معمولاً افزایش مییابد. انتخاب مدت قطعه باید با رفتار Player، کیفیت تطبیقی و هزینه پردازش و تحویل آزمایش شود.
برای شروع ظرفیتسنجی چه دادههایی لازم است؟
پیک نشست و نرخ شروع، مدت تماشا، ترکیب بیتریت، طول قطعه، نسبت کش بایتی، توان Origin و SLOهای Player حداقل ورودیها هستند. در نبود داده، چند سناریوی فرضی بسازید و آنها را صریحاً تخمینی بنامید.
جمعبندی: ظرفیت را همراه با فرضها گزارش کنید
خروجی محاسبه ظرفیت همزمان VOD باید بیشتر از یک عدد باشد: تعداد نشست قابل پشتیبانی، ترکیب کیفیت، نرخ شروع، وضعیت کش، حاشیه منابع، سناریوی خرابی و نتایج QoE را کنار هم ثبت کنید. ابتدا تقاضا و بیتریت را مدل کنید، سپس محدودیت هر لایه را بسنجید و در پایان با آزمون بار نتیجه را تأیید کنید.
برای تصمیم خرید یا توسعه زیرساخت، سه سناریوی عادی، پیک و خرابی را مقایسه کنید. هر تغییر مهم در نردبان کیفیت، Player، CDN یا سیاست کش میتواند ظرفیت را تغییر دهد و نیازمند بازبینی مدل است.