قياس الأداء

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

في هذه الصفحة

المنهجية أولًا

الإعداد

السيناريو 1 · نظيف، ضخم

190.6 GB → ملف mkv واحد بحجم 167.9 GB (أوروبا، 10 GbE)

nzbfast4m 33s
NZBGet 26.27m 58s · +75%
SABnzbd 5.0.419m 32s · +329%
rustnzb 1.3.4بلا خرج¹
nzbfastNZBGet 26.2SABnzbd 5.0.4rustnzb 1.3.4
الزمن حتى ملف قابل للاستخدام4m 33s7m 58s (+75%)19m 32s (+329%)لا شيء¹
GB على السلك169.6169.8169.7186.5
ذروة RSS1.4 GB²1.5 GB1.8 GB0.6 GB

¹ أنهى rustnzb نقل البايتات عند 5m 42s بعد أن سحب 186.5 GB (أكثر بـ 10% على السلك من أيّ منافس) لكنه لم يترك أي وسائط مستخرجة، وهذا شوطه الفاشل الثالث على التوالي على هذا المنشور. · ² تتبع ذاكرة nzbfast ميزانيته المُعدّة، لا المهمة: جرى هذا الشوط بالميزانية التلقائية الافتراضية وبلغ ذروة 1.4 GB؛ وميزانية ضخمة عمدًا قدرها 64 GB لا تشتري سوى 4% (4m 22s)، ومقيَّدًا عند 1 GB تكتمل مهمة 190 GB نفسها بعدُ (انظر سلّم الذاكرة المنخفضة أدناه). في شوط الساحل الشرقي الأسبق (خط ~2.4–3 Gbps) جرى السيناريو نفسه في 9m 00s مقابل NZBGet ‏+30% وSABnzbd ‏+111%. الفجوة صامدة عبر سرعات الخطوط.

السيناريو 2 · الفجوة تتّسع مع الحجم

الزمن حتى ملف قابل للاستخدام، حسب حجم المهمة

التمريرة الواحدة تعني لا تمريرة تحقق/فكّ ضغط بعد التنزيل، فكلما كبرت المهمة، ازداد تقدّمها في الوصول. أشواط تسلسلية على الجهاز نفسه:

المهمةnzbfastNZBGetSABnzbd
7.4 GB REMUX (أوروبا، 10 GbE)13.7 s17.3 s (+26%)19.0 s (+39%)
35 GB مموّه 4K (أوروبا)67 s108 s (+61%)285 s (+325%)
87 GB 4K (الساحل الشرقي)272 s370 s (+36%)708 s (+160%)
87 GB على قرص فيه 97 GB حرّة (أوروبا)3m 08sيتعذّر التشغيل²يتعذّر التشغيل²
190.6 GB (الساحل الشرقي)9m 00s11m 43s (+30%)19m 02s (+111%)

² تجاوز أثرهما الأقصى (المجلدات + الخرج المفكوك في آنٍ واحد، ~156 GB) الـ 97 GB الحرّة. تحتاج التمريرة الواحدة إلى ضعف واحد من حجم المحتوى: فتنصّف القرص الذي تحتاجه، لا الوقت فحسب.

السيناريو 3 · منشور مموّه

35 GB بأسماء تجزئة 4K → ملف mkv قابل للاستخدام (الساحل الشرقي)

nzbfastNZBGetSABnzbdrustnzb
الزمن حتى ملف قابل للاستخدام96 s153 s (+59%)259 s (+170%)لا ملف قابل للاستخدام³
ذروة RSS1.55 GB3.7 GB8.8 GB3.6 GB

³ نزّل rustnzb في 119 s، ووسم المهمة مكتملة، وسلّم المجلدات المموّهة الخام: بلا إعادة تسمية، بلا استخراج. أزال nzbfast التمويه من بيانات PAR2 الوصفية واستخرج أثناء البث، بصفر كتل معادة القراءة.

السيناريو 4 · قائمة انتظار من ثلاث

إبقاء الخط مضيئًا عبر قائمة انتظار (الساحل الشرقي، ~43 GB)

nzbfastrustnzbNZBGetSABnzbd
زمن ساعة حائط لقائمة الانتظار122 s136 s162 s277 s
خمول الخط (<20 MB/s)2 s (2%)16 s (12%)0 s168 s (61%)

ثلاثة أشكال للمشكلة نفسها: تداخل الذيل لدى nzbfast يُبقي الخط مشغولًا من طرف إلى طرف؛ وNZBGet لا يخمل أبدًا لكنه يعمل أبطأ بنحو 35% أثناء فكّ الضغط بالتزامن؛ وSABnzbd يُنزّل بسرعة، ثم يترك الخط مظلمًا 61% من الوقت أثناء المعالجة اللاحقة المتسلسلة. في متغيّر المرونة (مهمة واحدة بترويسات RAR مشفّرة)، انحشرت قائمة انتظار SABnzbd على المهمة المشفّرة ولم تكتمل سوى مهمة واحدة من 3؛ أما nzbfast فأركنها برسالة واضحة وأنهى البقية.

العمود الصادق

الأشواط التي لا نفوز بها

أُعيد قياس الشوطين اللذين كانا هنا على الإصدار المنشور، ولم يعد أيٌّ منهما خسارة: المنشور التالف بنمط store صار يكلّفنا 30 ثانية مقابل 38 لـNZBGet، وإعادة البناء من التكافؤ وحده تنتهي في 9 ثوانٍ بدل 19، في شوط يعود فيه NZBGet في الزمن نفسه لكنه لا يسلّم شيئًا. نُبقي هذا القسم مكانه بدل حذفه: هنا تذهب خسائرنا، والجولة التالية التي تجد واحدة ستعيدها إلى هنا.

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

السيناريو 6 · جوّعه من RAM

سلّم الذاكرة المنخفضة: 190 GB في ~1.1 GB من RAM

المهام الأربع نفسها، مُعادة التشغيل بميزانيات ذاكرة صارمة 2 GB و1 GB و256 MB: ما سيختاره المحدِّد التلقائي على جهاز 8 GB، وجهاز 4 GB، وNAS بـ 2 GB. أنتج كل شوط ملفًا صحيحًا، متحقَّقًا منه بالكامل، مستخرَجًا؛ وتتبّعت ذروة RSS الميزانية، لا المهمة. الزمن حتى ملف قابل للاستخدام، خط 10 GbE:

حجم المهمةوفرة من RAMميزانية 2 GBميزانية 1 GBميزانية 256 MB
7 GB15 s15 s15 s15 s
35 GB65 s70 s70 s65 s
87 GB148 s206 s196 s180 s
190 GB330 s427 s402 s411 s

علاوة الـ 20–40% على المهام الكبيرة هي أثر خاص بـ 10 GbE: الكتل المنسكبة لا تكلّف وقتًا إلا حين يسبق الخطُّ القرص. نفس مهمة 87 GB بالميزانيات نفسها على خط ~2.4 Gbps قاست −1% إلى +7%، ضوضاء. على اتصال منزلي نموذجي تكون الميزانية الصغيرة شبه مجانية عند أي حجم مهمة. أنهى ملفّ NAS (2 اتصال، ميزانية 256 MB) مهمة 35 GB بذروة RSS بمقدار 0.4 GB. يستطيع NAS بـ 2 GB تشغيل هذا. لا عميل آخر يقدّم سقف ذاكرة إطلاقًا.

السيناريو 7 · أرشيفات داخل أرشيفات

عشرة أشكال متداخلة: من يُنهي المهمة من دونك

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

الشكلnzbfastSABnzbdNZBGetrustnzb
RAR تخزين داخل RAR تخزينتلقائيتلقائييدوييدوي
RAR مضغوط داخل RAR تخزينتلقائيتلقائييدوييدوي
7z داخل RAR تخزينتلقائيتلقائييدوييدوي
سلّم من 5 مستويات، 6 حمولاتتلقائي · 6/6يدوي · 3/6يدوي · 1/6يدوي · 1/6
سلسلة كلمات مرور، 3 مستويات مشفّرةتلقائي · 3/3يطلب كلمة مروريطلب كلمة مرورفشل
إكمال تلقائي، الأشكال العشرة كلها8/106/102/102/10

منصة loopback، ومتن مولَّد آليًا، والعملاء الأربعة كلهم على الآلة نفسها، والتقييم بتجزئة المحتوى، فالعميل الذي يعيد تسمية الحمولة ينال حقه مع ذلك. ولأن الطبقات الداخلية تُفكّ من تداخلها أثناء التدفق، يحتفظ nzbfast بنسخة واحدة نحو 1.5 GB على القرص حيث يحتفظ عملاء الكتابة-ثم-الفكّ بنحو 3 GB، ويُنهي هذه الأشواط في 1–2 ثانية مقابل 4–8 ثوانٍ. في سلسلة كلمات المرور، تصل كلمة مرور كل طبقة في ملف تستخرجه الطبقة التي فوقها: يقرؤه nzbfast ويفتح المستويات الثلاثة كلها؛ بينما يتوقف الآخرون منتظرين أن تكتبها أنت. أما الشكلان اللذان لا يُكملهما تلقائيًا فيُقيَّمان بقسوة عن قصد: سلّم من 10 مستويات يتجاوز حدّ العمق الافتراضي، ومنشور تالف في مستوياته الثلاثة كلها. في كليهما يسترد حمولات أكثر من أي عميل آخر، لكنه يخرج برمز غير صفري بدل أن يسمّي مهمة ناقصة نجاحًا، ولذلك يُحسبان هنا فشلَين.

مبارزات المكوّنات

محركا الفكّ والإصلاح، في سباق منفرد

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

استخراج RAR · ‏8 أشكال أرشيف

أمام unrar 7.23 و7-Zip وbsdtar وunar وحزمة rars الأصلية على Apple M3 Ultra، يفوز مستخرج nzbfast أو يتعادل في كل شكل: 400 ملف صغير في 0.13 s مقابل 0.66 s لدى unrar، وsolid ‏0.50 مقابل 0.87، ومشفّر 0.49 مقابل 0.82، وأرشيف RAR7 بقاموس 128 MB ‏0.71 مقابل 0.92. وبإعادة التشغيل على M1 Ultra بـ 20 نواة وعلى حاسوب محمول Intel بـ 14 نواة تصمد النتيجة في كل شكل، وعلى الحاسوب المحمول تتسع الفوارق: مسارات فك التشفير المتوازية تتمدد في الخيوط الإضافية. كل زمن مُبلَّغ عنه أنتج خرجًا مطابقًا بـ sha256.

تحقق + إصلاح PAR2 · مجموعة 1 GiB

أمام par2cmdline الكلاسيكي وتفريعة SIMD ‏par2cmdline-turbo وأمام MultiPar، يملك nzbfast أسرع تحقق وأسرع إصلاح على كل آلة جرى قياسها. سطح مكتب بـ 20 نواة: تحقق نظيف 0.40 s مقابل 1.08 لدى turbo و3.67 لدى الكلاسيكي؛ وإصلاح 101 كتلة تالفة 1.26 s مقابل 2.61 و7.52. حاسوب محمول بـ 14 نواة: تحقق 1.26 مقابل 1.48، وإصلاح 2.57 مقابل 3.62. كل ملف مُصلَح مطابق بالبايت. ملاحظة صادقة واحدة: نحن لا ننشئ PAR2 (لا يحتاج المنزّل إلى ذلك، وهذا الشوط ملك ParPar).

ما تكلفة المهمة

ذروة استخدام القرص لحمولة 1.5 GB

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

الشكلnzbfastNZBGet 26.2rustnzb 1.3.4SABnzbd 5.0.4
‏RAR store داخل RAR store1538153817743080
طبقة داخلية مضغوطة1536153616743102
‏RAR داخل RAR، عمق 21536153617143076
‏7z ملفوف في RAR store1503153617223102

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

القدرة، لا القياسات الصغيرة

ما يستطيعه كل عميل

nzbfastSABnzbd 5NZBGet 26rustnzbUsenappNewsbin
NNTP متسلسل بالأنابيبنعممعطّل افتراضيًالانعم--
تحقق كامل أثناء التنزيلكل كتلةبعدهفحص سريعبعدهبعدهبعده
استخراج أثناء التنزيلأثناء البث، بلا مجلدات على القرصفكّ ضغط مباشر⁴فكّ ضغط مباشر⁴غير موثوق⁵لالا
القرص المطلوب لمنشور بحجم N-GB~1×N~2×N~2×N~2×N~2×N~2×N
حكم على قابلية الاكتمال قبل التنزيلدقيق بالكتلةلا% صحةلافحص المقالاتلا
ذاكرة مقيَّدة (لا مبادلة أبدًا)بميزانية9.3 GB عند 190 GBإعداد ذاكرة مؤقتةلا--
تحقّق من الملف عند أي نقطة أثناء التنزيلنعملالالاتسلسليلا
مفهرِس مدمج + جدار ملصقاتنعم، بلا مفاتيحلالالاواجهة بحثمتصفّح مجموعات
توافق مباشر مع Sonarr/Radarrواجهة SAB + Newznabأصيلأصيلجزئيلالا
تطبيقات هاتف عن بُعد (nzb360/LunaSea)عبر NZBGet RPCنعمنعملالالا
جلب تلقائي لقائمة المتابعة + ترقياتمدمجعبر *arrعبر *arrلاWatchdogقواعد
ملف تنفيذي واحد قائم بذاتهنعمPythonنعمنعم‏.app‏.exe
مفتوح المصدرGPL⁶GPLGPLنعممدفوعمدفوع
المنصّاتmac/win/linux/dockermac/win/linuxmac/win/linuxlinux/winmac فقطwin فقط

⁴ فكّ الضغط المباشر لا يزال يجسّد المجلدات أولًا: ضعف كتابة وضعف قرص. ⁵ سلّم rustnzb مجلدات مموّهة موسومة "مكتملة" في شوطنا (كما يتعلّق فكّ ضغطه مع RARLab unrar ما لم يُعطَّل). ⁶ GPL-3.0-or-later. وUsenapp/Newsbin قارئان تجاريان أحادِيَا المنصّة بميزات تنزيل؛ أُدرِجا لأن الناس يسألون، لا لأنهما ينافسان على السرعة.

إثبات النقل

المحرّك يُشبِع الخطوط الحقيقية

قاعدة ثابتة: كل ادّعاء أداء يذكر الظروف التي جرى فيها، بما في ذلك النتائج السلبية والمنعطفات الخاطئة.