ארבעה קליינטים, שבעה תרחישים, חומרה וספקים זהים, הרצות משולבות כך שסחיפת הספק מתקזזת. המדד הוא זמן לקובץ שמיש: מורד, מאומת, מחולץ. כולל את המקטעים שבהם איננו מנצחים.
בדף הזה
קודם המתודולוגיה
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 שנ', סימן את המשימה הושלמה, ושלח את הכרכים המעורפלים הגולמיים: בלי שינוי שם, בלי חילוץ. 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 לוקח לנו כעת 30 שניות מול 38 של NZBGet, ושחזור מפריטי בלבד מסתיים ב-9 שניות במקום 19, במקטע שבו 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 וחבילת ה-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, עומק 2 | 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 | SAB API + Newznab | מקורי | מקורי | חלקי | לא | לא |
| שלטי טלפון (nzb360/LunaSea) | דרך NZBGet RPC | כן | כן | לא | לא | לא |
| תפיסה אוטומטית ברשימת מעקב + שדרוגים | מובנה | דרך *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 שלח כרכים מעורפלים המסומנים "הושלמה" בסבב שלנו (הפריקה שלו גם נתקעת עם unrar של RARLab אלא אם מבוטלת). ⁶ GPL-3.0-or-later. Usenapp/Newsbin הם קוראים מסחריים חד-פלטפורמיים עם תכונות מוריד; הם מופיעים כי אנשים שואלים, לא כי הם מתחרים על מהירות.
הוכחת תעבורה