كم عدد المستخدمين الذين يمكن لـ Jellyfin دعمهم على خادم منزلي صغير؟

لا يوجد عدد ثابت وصادق للمستخدمين لخادم Jellyfin صغير، لأن مسارات التشغيل المتزامن ومعدلات البت أهم بكثير من الحسابات المسجلة.

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

المستخدمون المسجلون ليسوا مثل أحمال العمل المتزامنة

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

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

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

يحدّ التخزين والشبكة عادةً مستخدمي التشغيل المباشر أولًا

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

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

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

يستهلك مستخدمو تحويل الوسائط مجموعة سعة مختلفة

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

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

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

تغيّر الخدمات الخلفية وحالة ذاكرة التخزين المؤقت العدد نفسه من المستخدمين

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

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

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

حوّل المنزل إلى وحدات حمل وأضف المستخدمين حتى ينكسر الهامش

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

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

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