Fyra klienter, sju scenarier, identisk hårdvara och providers, körningar sammanflätade så att providerdrift tar ut sig. Måttet är tid till en användbar fil: nedladdad, verifierad, uppackad. Inklusive de etapper vi inte vinner.
På den här sidan
Metodik först
pipelining_requests=8 (den levereras med 1, dvs opipelinead; enbart den inställningen tog dess 190 GB-tid från 24m24s till 19m02s), NZBGet fick ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sin dokumenterade konfig.Scenario 1 · ren, enorm
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tid till användbar fil | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | ingen¹ |
| GB på tråden | 169.6 | 169.8 | 169.7 | 186.5 |
| toppar-RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb blev klar med att flytta bytes vid 5m 42s efter att ha dragit 186.5 GB (10 % mer tråd än någon annan) men lämnade ingen uppackad media, dess tredje raka misslyckade omgång på det här inlägget. · ² nzbfasts minne följer dess konfigurerade budget, inte jobbet: den här omgången körde standard-autobudgeten och toppade på 1.4 GB; en avsiktligt enorm 64 GB-budget köper bara 4 % (4m 22s), och begränsad till 1 GB blir samma 190 GB-jobb fortfarande klart (se lågminnesstegen nedan). På den tidigare östkusten-omgången (~2.4–3 Gbps-linje) körde samma scenario 9m 00s vs NZBGet +30 % och SABnzbd +111 %. Glappet håller över olika linjehastigheter.
Scenario 2 · glappet växer med storleken
Enpass betyder inget verifierings-/uppackningspass efter nedladdning, så ju större jobb, desto längre fram landar det. Sekventiella körningar på samma maskin:
| Jobb | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX (Europa, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB obfuskerad 4K (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (östkusten) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB på en disk med 97 GB ledigt (Europa) | 3m 08s | kan inte köra² | kan inte köra² |
| 190.6 GB (östkusten) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Deras toppfotavtryck (volymer + uppackad utdata samtidigt, ~156 GB) översteg de 97 GB lediga. Enpass behöver 1× innehållsstorleken: det halverar disken du behöver, inte bara tiden.
Scenario 3 · obfuskerat inlägg
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tid till användbar fil | 96 s | 153 s (+59%) | 259 s (+170%) | ingen användbar fil³ |
| toppar-RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb laddade ner på 119 s, markerade jobbet Completed, och levererade de råa obfuskerade volymerna: ingen omdöpning, ingen uppackning. nzbfast deobfuskerade från PAR2-metadata och packade upp i strömmen, noll återlästa block.
Scenario 4 · kö av tre
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| tid att beta av kön | 122 s | 136 s | 162 s | 277 s |
| linje i vila (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Tre former av samma problem: nzbfasts svansöverlappning håller linjen upptagen kant till kant; NZBGet vilar aldrig men kör ~35 % långsammare medan den packar upp samtidigt; SABnzbd laddar ner snabbt, och lämnar sedan linjen mörk 61 % av tiden under seriell efterbehandling. I motståndskraftsvarianten (ett jobb med krypterade RAR-headers) fastnade SABnzbds kö på det krypterade jobbet och bara 1 av 3 jobb blev någonsin klart; nzbfast parkerade det med ett tydligt meddelande och slutförde resten.
Den ärliga kolumnen
Båda grenarna som stod här har mätts om på det levererade bygget och ingen är längre en förlust: den skadade store-mode-posten tar oss nu 30 s mot NZBGets 38 s, och rekonstruktion enbart ur paritet är klar på 9 s där den tog 19 s, på en gren där NZBGet återkommer på samma tid men levererar ingenting. Vi låter avsnittet stå kvar i stället för att radera det: det är hit våra förluster går, och nästa omgång som hittar en sätter tillbaka den.
Scenario 6 · svält den på RAM
Samma fyra jobb, omkörda vid hårda minnesbudgetar på 2 GB, 1 GB och 256 MB: vad auto-dimensioneraren skulle välja på en 8 GB-maskin, en 4 GB-maskin och en 2 GB NAS. Varje etapp gav en korrekt, fullt verifierad, uppackad fil; toppar-RSS följde budgeten, inte jobbet. Tid till användbar fil, 10 GbE-linje:
| Jobbstorlek | gott om RAM | 2 GB budget | 1 GB budget | 256 MB budget |
|---|---|---|---|---|
| 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 |
Premien på 20–40 % på de stora jobben är en 10 GbE-artefakt: spillda block kostar bara tid när linjen springer om disken. Samma 87 GB-jobb vid samma budgetar på en ~2.4 Gbps-linje mätte −1 % till +7 %, brus. På en typisk hemuppkoppling är en liten budget nära gratis vid vilken jobbstorlek som helst. En NAS-profil (2 anslutningar, 256 MB budget) blev klar med 35 GB-jobbet i 0.4 GB toppar- RSS. En 2 GB NAS kan köra detta. Ingen annan klient erbjuder ett minnestak överhuvudtaget.
Scenario 7 · arkiv inuti arkiv
Inlägg anländer allt oftare nästlade: en RAR inuti en RAR, en 7z instoppad i ett store-arkiv, en stege av lager, en lösenordskedja. Den här omgången betygsätter vad som blir kvar åt operatören. auto betyder varje nyttolast uppackad, byte-identisk, utan händer; manuellt betyder att klienten rapporterade framgång men lämnade ett inre arkiv stående i utdatakatalogen åt dig att öppna själv.
| form | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| store-RAR inuti store-RAR | auto | auto | manuellt | manuellt |
| komprimerad RAR inuti store-RAR | auto | auto | manuellt | manuellt |
| 7z inuti en store-RAR | auto | auto | manuellt | manuellt |
| 5-nivåers stege, 6 nyttolaster | auto · 6/6 | manuellt · 3/6 | manuellt · 1/6 | manuellt · 1/6 |
| lösenordskedja, 3 krypterade nivåer | auto · 3/3 | ber om ett lösenord | ber om ett lösenord | misslyckades |
| automatiskt slutfört, alla tio former | 8/10 | 6/10 | 2/10 | 2/10 |
Loopback-rigg, maskingenererad korpus, alla fyra klienter på samma maskin, betygsatt via innehållshash, så en klient som döper om nyttolasten får ändå poäng. Eftersom inre lager avnästlas i farten håller nzbfast en enda ~1.5 GB-kopia på disk där skriv-ut-och-packa-upp-klienter håller ~3 GB, och blir klar med de här etapperna på 1–2 s mot 4–8 s. På lösenordskedjan skickas varje lagers lösenord i en fil som lagret ovanför packar upp: nzbfast läser den och låser upp alla tre nivåer; de andra stannar och väntar på att du ska skriva in det. De två former den inte klarar automatiskt betygsätts hårt med avsikt: en 10-nivåers stege bortom dess standarddjupgräns och ett inlägg skadat på alla tre nivåer. På båda återvinner den fler nyttolaster än någon annan klient, men avslutar med en kod skild från noll i stället för att kalla ett delvis jobb en framgång, så båda räknas som misslyckanden här.
Komponentdueller
Uppackning och PAR2 är vår egen inbyggda kod, så vi tävlar också med dem fristående mot fältet på identiska korpusar. En tid räknas bara när utdatan är byte-identisk med källnyttolasten.
Mot unrar 7.23, 7-Zip, bsdtar, unar och uppströms rars-craten på en Apple M3 Ultra vinner eller delar nzbfasts uppackare varje form: 400 små filer 0.13 s mot unrars 0.66 s, solid 0.50 vs 0.87, krypterad 0.49 vs 0.82, ett RAR7-arkiv med 128 MB-ordbok 0.71 vs 0.92. Omkörd på en 20-kärnig M1 Ultra och på en 14-kärnig Intel-laptop håller resultatet på varje form, och på laptopen breddas marginalerna: de parallella avkodningsvägarna skalar in i de extra trådarna. Varje rapporterad tid gav sha256-identisk utdata.
Mot klassiska par2cmdline, SIMD-forken par2cmdline-turbo och MultiPar har nzbfast den snabbaste verifieringen och den snabbaste reparationen på varje benchad maskin. 20-kärnig desktop: ren verifiering 0.40 s mot turbons 1.08 och klassikerns 3.67; reparation av 101 skadade block 1.26 s vs 2.61 och 7.52. 14-kärnig laptop: verifiering 1.26 vs 1.48, reparation 2.57 vs 3.62. Varje reparerad fil byte-identisk. En ärlig notering: vi skapar inte PAR2 (en nedladdare behöver inte det, och ParPar äger den etappen).
Vad ett jobb kostar
Löftet om en enda genomgång handlar lika mycket om disk som om hastighet, så här är det mätt i stället för påstått: det högsta arbetskatalogen någonsin nådde under de nästlade körningarna, avläst två gånger i sekunden. Att läsa en gång på slutet skulle inte säga något, eftersom en klient som raderar sina volymer efter uppackning skulle se ut att aldrig ha skrivit dem.
| form | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| store-RAR i store-RAR | 1538 | 1538 | 1774 | 3080 |
| komprimerat inre lager | 1536 | 1536 | 1674 | 3102 |
| RAR i RAR, djup 2 | 1536 | 1536 | 1714 | 3076 |
| 7z inlindad i en store-RAR | 1503 | 1536 | 1722 | 3102 |
Megabyte, lägre är bättre. NZBGet går jämsides med oss här och det är värt att säga varför: den kör med DirectUnpack och DirectWrite på, vilket är hur vi ställer in varje konkurrent, och på de här formerna räcker det för en enda kopia på disk. SABnzbd håller två. Gapet som återstår är det pipelinen byggdes för: vi materialiserar aldrig volymerna, så toppen är nyttolasten själv i stället för nyttolasten plus arkivet som bar den.
Förmåga, inte mikrobenchmarks
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| pipelinead NNTP | ja | av som standard | nej | ja | - | - |
| full verifiering under nedladdning | varje block | efteråt | snabbkoll | efteråt | efteråt | efteråt |
| uppackning under nedladdning | i strömmen, inga volymer på disk | direktuppackning⁴ | direktuppackning⁴ | otillförlitlig⁵ | nej | nej |
| disk som behövs för ett N-GB-inlägg | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| utlåtande om slutförbarhet före nedladdning | blockexakt | nej | hälsa % | nej | artikelkoll | nej |
| begränsat minne (swappar aldrig) | budgeterat | 9.3 GB @ 190 GB | cache-inställning | nej | - | - |
| kontrollera filen på valfri punkt under nedladdningen | ja | nej | nej | nej | sekventiell | nej |
| inbyggd indexerare + postervägg | ja, nyckellös | nej | nej | nej | sök-UI | gruppbläddrare |
| Sonarr/Radarr drop-in | SAB API + Newznab | native | native | delvis | nej | nej |
| telefonfjärrar (nzb360/LunaSea) | via NZBGet RPC | ja | ja | nej | nej | nej |
| bevakningslista auto-grab + uppgraderingar | inbyggt | via *arr | via *arr | nej | Watchdog | regler |
| en enda fristående binär | ja | Python | ja | ja | .app | .exe |
| öppen källkod | GPL⁶ | GPL | GPL | ja | betald | betald |
| plattformar | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | endast mac | endast win |
⁴ Direktuppackning materialiserar fortfarande volymerna först: 2× skrivningar och 2× disk. ⁵ rustnzb levererade obfuskerade volymer markerade "Completed" i vår omgång (dess uppackning hänger också med RARLab unrar om den inte inaktiveras). ⁶ GPL-3.0-or-later. Usenapp/Newsbin är enplattforms kommersiella läsare med nedladdningsfunktioner; de listas för att folk frågar, inte för att de konkurrerar på hastighet.
Transportbevis