چهار کلاینت، هفت سناریو، سختافزار و ارائهدهندههای یکسان، اجراها درهمتنیده تا رانش ارائهدهنده خنثی شود. معیار زمان تا یک فایل قابلاستفاده است: دانلودشده، تأییدشده، استخراجشده. شامل لِگهایی که در آنها نمیبریم.
در این صفحه
اول روششناسی
pipelining_requests=8 رسید (با 1 عرضه میشود، یعنی بدون خطلوله؛ همان تنظیم بهتنهایی زمان 190 GB آن را از 24m24s به 19m02s رساند)، NZBGet به ArticleCache/DirectWrite/DirectUnpack/ParQuick، rustnzb به پیکربندی مستندش.سناریو 1 · تمیز، عظیم
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| زمان تا فایل قابلاستفاده | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | هیچ¹ |
| GB روی سیم | 169.6 | 169.8 | 169.7 | 186.5 |
| اوج RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.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 · فاصله با اندازه رشد میکند
تکگذر یعنی بدون گذر تأیید/باز کردن پس از دانلود، پس هرچه کار بزرگتر باشد، جلوتر فرود میآید. اجراهای متوالی روی همان ماشین:
| کار | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX (اروپا، 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB مبهم 4K (اروپا) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (ساحل شرقی) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB روی دیسک با 97 GB آزاد (اروپا) | 3m 08s | نمیتواند اجرا شود² | نمیتواند اجرا شود² |
| 190.6 GB (ساحل شرقی) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² اوج ردپای آنها (جلدها + خروجی بازشده همزمان، ~156 GB) از 97 GB آزاد فراتر رفت. تکگذر به 1× اندازهٔ محتوا نیاز دارد: دیسک موردنیاز شما را نصف میکند، نه فقط زمان را.
سناریو 3 · پست مبهم
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| زمان تا فایل قابلاستفاده | 96 s | 153 s (+59%) | 259 s (+170%) | بدون فایل قابلاستفاده³ |
| اوج RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb در 119 s دانلود کرد، کار را تمامشده نشاندار کرد، و جلدهای مبهم خام را تحویل داد: بدون تغییرنام، بدون استخراج. nzbfast از فرادادهٔ PAR2 ابهامزدایی و در جریان استخراج کرد، صفر بلوک بازخوانی.
سناریو 4 · صف سهتایی
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| زمان دیواری صف | 122 s | 136 s | 162 s | 277 s |
| بیکاری خط (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
سه شکل از یک مسئله: همپوشانی-دنبالهٔ nzbfast خط را از لبه تا لبه مشغول نگه میدارد؛ NZBGet هرگز بیکار نمیشود اما در حین باز کردن همزمان ~35% کندتر اجرا میشود؛ SABnzbd سریع دانلود میکند، سپس خط را در طول پسپردازش سریالی 61% اوقات خاموش رها میکند. در گونهٔ تابآوری (یک کار با هدرهای RAR رمزگذاریشده)، صف SABnzbd روی کار رمزگذاریشده گیر کرد و تنها 1 از 3 کار اصلاً کامل شد؛ nzbfast آن را با یک پیام روشن پارک کرد و بقیه را تمام کرد.
ستون صادقانه
هر دو مرحلهای که اینجا بودند روی نسخهٔ منتشرشده دوباره اندازهگیری شدند و هیچکدام دیگر باخت نیستند: پست آسیبدیدهٔ حالت store اکنون ۳۰ ثانیه از ما میگیرد در برابر ۳۸ ثانیهٔ NZBGet، و بازسازی تنها از روی توازن در ۹ ثانیه تمام میشود بهجای ۱۹ ثانیه، در مرحلهای که NZBGet در همان زمان بازمیگردد اما چیزی تحویل نمیدهد. این بخش را بهجای حذف، سر جایش نگه میداریم: باختهای ما اینجا میآیند و دور بعدی که یکی پیدا کند، آن را همینجا میگذارد.
سناریو 6 · آن را از 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 GB | 15 s | 15 s | 15 s | 15 s |
| 35 GB | 65 s | 70 s | 70 s | 65 s |
| 87 GB | 148 s | 206 s | 196 s | 180 s |
| 190 GB | 330 s | 427 s | 402 s | 411 s |
سربار 20–40% روی کارهای بزرگ یک اثر 10 GbE است: بلوکهای سرریزشده فقط وقتی وقتگیرند که خط از دیسک جلو بزند. همان کار 87 GB با همان بودجهها روی یک خط ~2.4 Gbps معادل −1% تا +7% سنجیده شد، نوفه. روی یک اتصال خانگی معمولی یک بودجهٔ کوچک در هر اندازهٔ کار تقریباً رایگان است. یک نمای NAS (2 اتصال، بودجهٔ 256 MB) کار 35 GB را در 0.4 GB اوج RSS تمام کرد. یک NAS 2 GB میتواند این را اجرا کند. هیچ کلاینت دیگری اصلاً سقف حافظه ارائه نمیدهد.
سناریو 7 · آرشیو درون آرشیو
پستها روزبهروز تودرتوتر میرسند: یک RAR درون یک RAR، یک 7z جاسازیشده در یک آرشیو حالت-ذخیره، نردبانی از لایهها، یک زنجیرهٔ رمز عبور. این دور آنچه را که برای اپراتور باقی میماند نمره میدهد. خودکار یعنی همهٔ محمولهها استخراج شدند، بایتبهبایت یکسان، بدون دخالت دست؛ دستی یعنی کلاینت موفقیت گزارش داد اما یک آرشیو درونی را در پوشهٔ خروجی جا گذاشت تا خودتان بازش کنید.
| شکل | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| RAR حالت-ذخیره درون RAR حالت-ذخیره | خودکار | خودکار | دستی | دستی |
| RAR فشرده درون RAR حالت-ذخیره | خودکار | خودکار | دستی | دستی |
| 7z درون یک RAR حالت-ذخیره | خودکار | خودکار | دستی | دستی |
| نردبان 5 سطحی، 6 محموله | خودکار · 6/6 | دستی · 3/6 | دستی · 1/6 | دستی · 1/6 |
| زنجیرهٔ رمز عبور، 3 سطح رمزگذاریشده | خودکار · 3/3 | رمز عبور میخواهد | رمز عبور میخواهد | شکست خورد |
| تکمیل خودکار، هر ده شکل | 8/10 | 6/10 | 2/10 | 2/10 |
سکوی loopback، پیکرهٔ ماشینساخته، هر چهار کلاینت روی یک ماشین، نمرهدهی با هش محتوا، پس کلاینتی که محموله را تغییرنام دهد باز هم امتیازش را میگیرد. چون لایههای درونی در حین جریان از تودرتویی درمیآیند، nzbfast یک نسخهٔ ~1.5 GB روی دیسک نگه میدارد جایی که کلاینتهای بنویس-و-باز-کن ~3 GB نگه میدارند، و این لِگها را در 1–2 ثانیه در برابر 4–8 ثانیه تمام میکند. در زنجیرهٔ رمز عبور، رمز هر لایه در فایلی میآید که لایهٔ بالاییاش استخراج میکند: nzbfast آن را میخواند و هر سه سطح را باز میکند؛ دیگران میایستند و منتظر میمانند تا خودتان تایپش کنید. دو شکلی که بهطور خودکار تکمیل نمیکند عمداً سختگیرانه نمره داده شدهاند: نردبانی 10 سطحی فراتر از سقف عمق پیشفرضش و پستی که در هر سه سطح خراب است. در هر دو، محمولههای بیشتری از هر کلاینت دیگری بازیابی میکند، اما بهجای آنکه کار ناقص را موفقیت بنامد با کد غیرصفر خارج میشود، پس هر دو اینجا شکست حساب میشوند.
دوئل اجزا
استخراج و PAR2 کد بومی خود ما هستند، پس آنها را جداگانه هم روی پیکرههای یکسان با میدان مسابقه میدهیم. یک زمان فقط وقتی حساب میشود که خروجی بایتبهبایت با محمولهٔ منبع یکسان باشد.
در برابر unrar 7.23، 7-Zip، bsdtar، unar و crate بالادستی 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-یکسان تولید کرد.
در برابر 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 است).
یک کار چه هزینهای دارد
ادعای تکگذر به همان اندازه که به سرعت مربوط است به دیسک هم مربوط میشود؛ پس این هم اندازهگیریشده و نه ادعاشده: بالاترین حدی که پوشهٔ کاری در طول اجراهای تودرتو به آن رسید، با نمونهبرداری دو بار در ثانیه. یک بار خواندن در پایان هیچ نمیگفت، چون کلاینتی که پس از استخراج جلدهایش را پاک میکند چنان به نظر میرسد که هرگز آنها را ننوشته است.
| شکل | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| RAR store درون RAR store | 1538 | 1538 | 1774 | 3080 |
| لایهٔ درونی فشرده | 1536 | 1536 | 1674 | 3102 |
| RAR درون RAR، عمق ۲ | 1536 | 1536 | 1714 | 3076 |
| 7z پیچیده در یک RAR store | 1503 | 1536 | 1722 | 3102 |
مگابایت، کمتر بهتر است. NZBGet اینجا با ما برابر است و گفتن دلیلش میارزد: با DirectUnpack و DirectWrite روشن اجرا میشود، همانطور که هر رقیب را پیکربندی میکنیم، و در این شکلها همین برای یک نسخه روی دیسک کافی است. SABnzbd دو نسخه نگه میدارد. فاصلهای که میماند همان است که خط لوله برایش ساخته شد: ما اصلاً جلدها را روی دیسک پدید نمیآوریم، پس اوج همان محتواست نه محتوا بهعلاوهٔ آرشیوی که آن را حمل میکرد.
توانمندی، نه ریزمحکها
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| NNTP خطلولهای | بله | بهطور پیشفرض خاموش | خیر | بله | - | - |
| تأیید کامل حین دانلود | هر بلوک | پس از آن | بررسی سریع | پس از آن | پس از آن | پس از آن |
| استخراج حین دانلود | در جریان، بدون جلد روی دیسک | باز کردن مستقیم⁴ | باز کردن مستقیم⁴ | نامطمئن⁵ | خیر | خیر |
| دیسک موردنیاز برای یک پست N-GB | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| حکم قابلتکمیل بودن پیش از دانلود | بلوک-دقیق | خیر | درصد سلامت | خیر | بررسی مقاله | خیر |
| حافظهٔ کراندار (هرگز swap) | بودجهبندیشده | 9.3 GB @ 190 GB | تنظیم حافظهٔ نهان | خیر | - | - |
| بررسی فایل در هر نقطه حین دانلود | بله | خیر | خیر | خیر | سریالی | خیر |
| ایندکسر داخلی + دیوار پوستر | بله، بدون کلید | خیر | خیر | خیر | رابط جستوجو | مرورگر گروه |
| جایگزین Sonarr/Radarr | API SAB + Newznab | بومی | بومی | جزئی | خیر | خیر |
| کنترلهای گوشی (nzb360/LunaSea) | از طریق RPC NZBGet | بله | بله | خیر | خیر | خیر |
| گرفتن خودکار فهرست پیگیری + ارتقاها | درونساخت | از طریق *arr | از طریق *arr | خیر | Watchdog | قواعد |
| یک باینری خودکفای واحد | بله | Python | بله | بله | .app | .exe |
| متنباز | GPL⁶ | GPL | GPL | بله | پولی | پولی |
| پلتفرمها | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | فقط mac | فقط win |
⁴ باز کردن مستقیم هنوز اول جلدها را مادی میکند: 2× نوشتن و 2× دیسک. ⁵ rustnzb در دور ما جلدهای مبهم را با نشان «Completed» تحویل داد (باز کردنش هم با unrar از RARLab قفل میشود مگر غیرفعال شود). ⁶ GPL-3.0-or-later. Usenapp/Newsbin خوانندههای تجاری تکپلتفرمی با قابلیتهای دانلودر هستند؛ به این دلیل فهرست شدهاند که مردم میپرسند، نه چون بر سر سرعت رقابت میکنند.
اثبات انتقال