كم عدد المستخدمين المتزامنين الذين يستطيع Plex التعامل معهم قبل أن يتباطأ؟

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

لا يوجد حد عالمي مفيد لعدد مستخدمي Plex؛ فالتزامن المستقر لديك هو أكبر مزيج فعلي من الجلسات يمر بنجاح قبل أن يفقد التخزين أو الشبكة أو التحويل الترميزي هامش الأمان.

قد يكون تشغيل عشرة مستخدمين للمحتوى مباشرةً أخف من عمليتي تحويل ترميزي عن بُعد تتطلبان موارد كبيرة، كما قد يتعثر خادم يبدو مريحًا أثناء التشغيل المستقر عندما يبدأ عدة مشاهدين التشغيل أو يستخدمون التقديم معًا. احسب أوضاع التشغيل الفعلية، ومعدلات نقل البيانات، ومسارات الترجمة وHDR، واستخدام الرفع عن بُعد. ثم أضف الجلسات التمثيلية واحدة تلو الأخرى، وتوقف عند أول اختناق قابل للتكرار بدلًا من تقدير السعة بناءً على طراز وحدة المعالجة المركزية أو عدد الحسابات.

احسب مسارات التشغيل، لا الحسابات

عدد الأشخاص الذين لديهم صلاحية الوصول إلى Plex ليس عدد أحمال العمل المتزامنة. ابدأ بمراقبة أكثر فترة ازدحامًا فعلية، وصنّف كل جلسة نشطة على أنها تشغيل مباشر، أو بث مباشر مع تحويل الحاوية، أو تحويل صوت فقط، أو تحويل فيديو ترميزي. تستهلك هذه الأوضاع موارد مختلفة جدًا من الخادم.

يمكن أن تنتج عشر جلسات متزامنة أو أكثر حدودًا مختلفة جدًا، اعتمادًا على عدد مسارات التشغيل المباشر، وإعادة التغليف، وتحويل الصوت، والتحويل الفيديوي الترميزي النشطة. ولا يستطيع العدد الخام للمستخدمين التنبؤ بنقطة التباطؤ.

أنشئ مجموعة اختبار انطلاقًا من أقصى تداخل معقول، لا من إجمالي أفراد المنزل أو قائمة الأصدقاء. فإذا كان ستة مستخدمين نادرًا ما يتداخلون وجميعهم يستخدمون التشغيل المباشر، فهذه مشكلة سعة مختلفة عن ثلاث عمليات تحويل ترميزي متزامنة بدقة 4K.

اعثر على أول مورد مشترك يفقد هامش الأمان

تتشارك الجلسات المتزامنة في تخزين الوسائط، وواجهة شبكة الخادم، وموارد وحدة المعالجة المركزية اللازمة للصوت والترجمات، ومساحة التخزين المؤقت للتحويل الترميزي، وأي محرك فيديو عتادي يُستخدم للتحويل. ويكون الحد هو المورد المطلوب الذي يفشل أولًا ضمن المزيج الفعلي، لا المكوّن الذي يحمل أعلى رقم في المواصفات.

قد تكشف أحمال Plex عالية التزامن عن اختناقات متعددة عبر الأقراص والشبكات والتحويل الترميزي ومسارات البيانات الداخلية. استخدم المنظور نفسه متعدد الموارد على نطاق خادم منزلي أصغر.

سجّل زمن استجابة قرص الوسائط، ومعدل نقل الشبكة، واستخدام وحدة المعالجة المركزية، ومحركات الفيديو في وحدة معالجة الرسومات، وضغط الذاكرة، وسرعة التحويل الترميزي أثناء إضافة الجلسات واحدة تلو الأخرى. ويكون أول مقياس يفقد هامش الأمان باستمرار عند النقطة نفسها التي تتدهور فيها جودة التشغيل هو حد السعة المفيد.

يضيف المستخدمون عن بُعد حدًا منفصلًا للرفع

يمكن أن تبقى التدفقات المحلية بالكامل داخل شبكة محلية سريعة، بينما تشترك كل التدفقات البعيدة في اتصال الإنترنت الصاعد للمنزل. وحتى الخادم القوي قد يبدو بطيئًا للمستخدم عندما تتجاوز معدلات البت الأصلية أو المحوّلة مجتمعةً سعة الرفع المتاحة بعد احتساب حركة المرور المنزلية الأخرى.

يجب أن تتعامل سعة الاستخدام عن بُعد مع سعة الشبكة والتحويل الترميزي كسقفين منفصلين. فوحدة معالجة رسومات أسرع لا تستطيع جعل وصلة WAN محمّلة تنقل بيانات أكثر.

اختبر التزامن عن بُعد من خارج المنزل، لا بفتح عدة علامات تبويب محلية في المتصفح. فإذا كان الرفع هو السقف الأول، فاخفض معدلات البت عن بُعد أو حسّن الاتصال قبل شراء وحدة معالجة مركزية إضافية. وإذا ظل الرفع مريحًا وانخفضت سرعة التحويل الترميزي، فسيكون مسار المعالجة هو الحد الأقوى.

-15% OFF

تكشف عمليات البدء والتقديم عن هامش الأمان أثناء الاندفاعات

غالبًا ما يكون التشغيل المستقر أسهل من بدء عدة مستخدمين التشغيل أو استخدامهم التقديم معًا. إذ تنشئ تلك اللحظات عمليات قراءة اندفاعية، ومخازن مؤقتة جديدة، وطلبات بيانات وصفية، وتدفقات شبكة جديدة قبل استقرار الحمل.

لا يكفي تحديد عدد ثابت من التدفقات من أجل التخطيط للتحويل الترميزي المتزامن؛ إذ يجب أن يتضمن اختبار القبول تنسيقات الملفات، ومعدلات البت المستهدفة، ومسارات الترجمة، وأعمال التحويل التي قد تبدأ في الوقت نفسه.

سجّل زمن الوصول إلى الإطار الأول واستعادة التشغيل بعد التقديم بينما يكون مزيج الجلسات المستهدف نشطًا بالفعل. فإذا فشلت عمليات البدء المتزامنة فقط، فقد يكون الحد ناتجًا عن تخزين اندفاعي أو زمن استجابة حالة التطبيق أو الاصطفاف، لا عن المعالجة المستمرة.

قد تخفض المهام الخلفية هامش الأمان نفسه

قد تستهلك عمليات الفحص والنسخ الاحتياطي والتنزيل والتحليل سعة التخزين أو وحدة المعالجة المركزية أو الذاكرة أو الشبكة نفسها التي يحتاج إليها المشاهدون النشطون. لذلك قد ينجح خادم في اختبار هادئ ويفشل في ذروة الاستخدام المنزلية الفعلية.

شغّل مزيج الجلسات المستهدف مرةً مع إيقاف الصيانة غير الضرورية مؤقتًا، ومرةً مع تشغيل مهمة خلفية تمثيلية واحدة. ويوضح الفرق ما إذا كان ضبط الجدولة، بدلًا من شراء عتاد أكبر، يمكن أن يستعيد هامش الأمان.

إذا استمر فشل التشغيل مع إيقاف العمل الخلفي مؤقتًا، فأبقِ حد التزامن ضمن مسار التشغيل. وإذا اختفى الفشل، فجدول المهمة المتنافسة أو اعزلها، وحافظ على خط أساس الخادم الأقل تكلفة.

احتفظ بتعريفات حمل العمل الناجح والفاشل معًا في دليل التشغيل. فهذا يجعل الحد التشغيلي قابلًا لإعادة الإنتاج بعد تغيير عميل أو برنامج ترميز أو مجموعة تخزين أو مهمة مجدولة.

حدّد حدًا تشغيليًا من اختبار متكرر

حد التزامن المفيد هو مزيج التزامن المستقر والمتكرر، وليس أعلى عدد يعمل لمدة ثلاثين ثانية. شغّل محتوى تمثيليًا عبر المشاهد الصعبة، واستخدم التقديم مرة واحدة، وراقب النظام مدة كافية حتى تستقر درجات الحرارة وقوائم الانتظار وسرعة التحويل الترميزي.

لا يحدد اختبار حمل 4K عن بُعد العتاد بدقة إلا بعد معرفة متطلبات التشغيل المباشر والرفع والتحويل الترميزي، وبذلك يظل حد التزامن مرتبطًا بالعمل المقاس بدلًا من عدد الحسابات.

وثّق المزيج الناجح وأول نمط فشل. فإذا أدت إضافة تدفق مباشر واحد إلى تشبع الشبكة، فحدك قائم على الشبكة. وإذا أدى تحويل ترميزي إضافي إلى انخفاض السرعة عن الزمن الحقيقي، فحدك قائم على المعالجة. أعد الاختبار بعد التغييرات الكبيرة في العميل أو برنامج الترميز أو التخزين أو الشبكة، بدلًا من اعتبار الرقم دائمًا.

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.