Fire klienter, sju scenarioer, identisk maskinvare og leverandører, kjøringer flettet så leverandørdrift kanselleres. Målingen er tid til en brukbar fil: lastet ned, verifisert, utpakket. Inkluderer de etappene vi ikke vinner.
På denne siden
Metode først
pipelining_requests=8 (den leveres med 1, dvs. upipelinet; den innstillingen alene tok 190 GB-tiden dens fra 24m24s til 19m02s), NZBGet fikk ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sin dokumenterte konfigurasjon.Scenario 1 · ren, enorm
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tid til brukbar fil | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | ingen¹ |
| GB på tråden | 169.6 | 169.8 | 169.7 | 186.5 |
| topp-RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb ble ferdig med å flytte bytes på 5m 42s etter å ha dratt 186.5 GB (10 % mer tråd enn noen andre), men etterlot ingen utpakkede medier, dens tredje mislykkede runde på rad på denne posten. · ² nzbfasts minne følger sitt konfigurerte budsjett, ikke jobben: denne runden kjørte det standard auto-budsjettet og toppet på 1.4 GB; et bevisst enormt 64 GB-budsjett kjøper bare 4 % (4m 22s), og avgrenset til 1 GB fullføres den samme 190 GB-jobben fortsatt (se lav-minne-stigen nedenfor). På den tidligere østkysten-runden (~2,4–3 Gbps-linje) kjørte det samme scenarioet 9m 00s vs. NZBGet +30 % og SABnzbd +111 %. Gapet holder på tvers av linjefarter.
Scenario 2 · gapet vokser med størrelsen
Én omgang betyr ingen verifiserings-/utpakkingsrunde etter nedlasting, så jo større jobben er, desto lengre foran lander den. Sekvensielle kjøringer på samme 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 obfuskert 4K (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (østkysten) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB på en disk med 97 GB ledig (Europa) | 3m 08s | kan ikke kjøre² | kan ikke kjøre² |
| 190.6 GB (østkysten) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Deres topp-fotavtrykk (volumer + utpakkede utdata samtidig, ~156 GB) oversteg de 97 GB ledige. Én omgang trenger 1× innholdsstørrelsen: den halverer disken du trenger, ikke bare tiden.
Scenario 3 · obfuskert post
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tid til brukbar fil | 96 s | 153 s (+59%) | 259 s (+170%) | ingen brukbar fil³ |
| topp-RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb lastet ned på 119 s, merket jobben Completed, og leverte de rå obfuskerte volumene: ingen omdøping, ingen utpakking. nzbfast deobfuskerte fra PAR2-metadata og pakket ut i strømmen, null innleste blokker.
Scenario 4 · kø på tre
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| kø-veggtid | 122 s | 136 s | 162 s | 277 s |
| linje inaktiv (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Tre former av det samme problemet: nzbfasts hale-overlapp holder linjen opptatt fra kant til kant; NZBGet står aldri ledig, men kjører ~35 % tregere mens den pakker ut samtidig; SABnzbd laster ned raskt, og lar så linjen ligge mørk 61 % av tiden under seriell etterbehandling. I robusthetsvarianten (én jobb med krypterte RAR-headere), kilte SABnzbds kø seg fast på den krypterte jobben, og bare 1 av 3 jobber ble noen gang fullført; nzbfast parkerte den med en tydelig melding og gjorde ferdig resten.
Den ærlige spalten
Begge testene som stod her er målt på nytt på den utgitte builden, og ingen av dem er lenger et tap: den skadede store-mode-posten tar oss nå 30 s mot NZBGets 38 s, og rekonstruksjon bare fra paritet er ferdig på 9 s der den tok 19 s, på en test der NZBGet kommer tilbake på samme tid, men ikke leverer noe. Vi lar seksjonen bli stående i stedet for å slette den: det er hit tapene våre går, og neste runde som finner ett, setter det tilbake.
Scenario 6 · sult den på RAM
De samme fire jobbene, kjørt på nytt ved harde minnebudsjetter på 2 GB, 1 GB og 256 MB: det auto-dimensjoneringen ville valgt på en 8 GB-maskin, en 4 GB-maskin og en 2 GB NAS. Hver etappe produserte en korrekt, fullstendig verifisert, utpakket fil; topp-RSS fulgte budsjettet, ikke jobben. Tid til brukbar fil, 10 GbE-linje:
| Jobbstørrelse | rikelig med RAM | 2 GB-budsjett | 1 GB-budsjett | 256 MB-budsjett |
|---|---|---|---|---|
| 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 |
De 20–40 % ekstra på de store jobbene er et 10 GbE-artefakt: spilte blokker koster bare tid når linjen er raskere enn disken. Den samme 87 GB-jobben ved de samme budsjettene på en ~2,4 Gbps-linje målte −1 % til +7 %, støy. På en typisk hjemmetilkobling er et lite budsjett nær gratis ved enhver jobbstørrelse. En NAS-profil (2 tilkoblinger, 256 MB-budsjett) gjorde ferdig 35 GB-jobben på 0.4 GB topp- RSS. En 2 GB NAS kan kjøre dette. Ingen annen klient tilbyr et minnetak i det hele tatt.
Scenario 7 · arkiver inni arkiver
Poster ankommer i økende grad nøstet: en RAR inni en RAR, en 7z stukket inn i et store-arkiv, en stige av lag, en passordkjede. Denne runden bedømmer hva som er igjen til operatøren. auto betyr hver nyttelast pakket ut, byte-identisk, uten hender; manuelt betyr at klienten meldte suksess, men etterlot et indre arkiv stående i utdatamappen som du selv må åpne.
| form | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| store-RAR inni store-RAR | auto | auto | manuelt | manuelt |
| komprimert RAR inni store-RAR | auto | auto | manuelt | manuelt |
| 7z inni en store-RAR | auto | auto | manuelt | manuelt |
| 5-nivåers stige, 6 nyttelaster | auto · 6/6 | manuelt · 3/6 | manuelt · 1/6 | manuelt · 1/6 |
| passordkjede, 3 krypterte nivåer | auto · 3/3 | ber om et passord | ber om et passord | feilet |
| auto-fullført, alle ti formene | 8/10 | 6/10 | 2/10 | 2/10 |
Loopback-rigg, maskingenerert korpus, alle fire klientene på samme maskin, bedømt etter innholdshash, så en klient som gir nyttelasten nytt navn får fortsatt uttelling. Fordi indre lag avnøstes i farten, holder nzbfast én ~1.5 GB-kopi på disk der skriv-ut-og-pakk-ut-klienter holder ~3 GB, og blir ferdig med disse etappene på 1–2 s mot 4–8 s. På passordkjeden leveres hvert lags passord i en fil som laget over pakker ut: nzbfast leser den og låser opp alle tre nivåene; de andre stopper og venter på at du skal taste det inn. De to formene den ikke auto-fullfører bedømmes hardt med vilje: en 10-nivåers stige forbi dens standard dybdegrense og en post skadet på alle tre nivåene. På begge gjenvinner den flere nyttelaster enn noen annen klient, men avslutter med en kode ulik null i stedet for å kalle en delvis jobb en suksess, så begge teller som feil her.
Komponentdueller
Utpakking og PAR2 er vår egen native kode, så vi kjører dem også frittstående mot feltet på identiske korpus. En tid teller bare når utdataen er byte-identisk med kildenyttelasten.
Mot unrar 7.23, 7-Zip, bsdtar, unar og oppstrøms rars-craten på en Apple M3 Ultra vinner eller deler nzbfasts utpakker hver form: 400 små filer 0.13 s mot unrars 0.66 s, solid 0.50 mot 0.87, kryptert 0.49 mot 0.82, et RAR7-arkiv med 128 MB-ordbok 0.71 mot 0.92. Kjørt på nytt på en 20-kjerners M1 Ultra og på en 14-kjerners Intel-laptop holder resultatet på hver form, og på laptopen blir marginene bredere: de parallelle dekodingsstiene skalerer inn i de ekstra trådene. Hver rapportert tid ga sha256-identisk utdata.
Mot klassisk par2cmdline, SIMD-forken par2cmdline-turbo og MultiPar har nzbfast den raskeste verifiseringen og den raskeste reparasjonen på hver maskin som er benchet. 20-kjerners desktop: ren verifisering 0.40 s mot turboens 1.08 og klassikerens 3.67; reparasjon av 101 skadede blokker 1.26 s mot 2.61 og 7.52. 14-kjerners laptop: verifisering 1.26 mot 1.48, reparasjon 2.57 mot 3.62. Hver reparert fil byte-identisk. En ærlig merknad: vi lager ikke PAR2 (en nedlaster trenger ikke det, og ParPar eier den etappen).
Hva en jobb koster
Løftet om én gjennomgang handler like mye om disk som om fart, så her er det målt i stedet for påstått: det høyeste arbeidskatalogen nådde under de nøstede kjøringene, avlest to ganger i sekundet. Én avlesning til slutt ville ikke si noe, for en klient som sletter volumene sine etter utpakking ville se ut som om den aldri hadde skrevet dem.
| form | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| store-RAR i store-RAR | 1538 | 1538 | 1774 | 3080 |
| komprimert indre lag | 1536 | 1536 | 1674 | 3102 |
| RAR i RAR, dybde 2 | 1536 | 1536 | 1714 | 3076 |
| 7z pakket i en store-RAR | 1503 | 1536 | 1722 | 3102 |
Megabyte, lavere er bedre. NZBGet er på høyde med oss her, og det er verdt å si hvorfor: den kjører med DirectUnpack og DirectWrite på, slik vi setter opp enhver konkurrent, og på disse formene holder det til én kopi på disken. SABnzbd holder to. Forskjellen som står igjen er den pipelinen ble bygget for: vi materialiserer aldri volumene, så toppen er nyttelasten selv i stedet for nyttelasten pluss arkivet som bar den.
Kapabilitet, ikke mikro-benchmarker
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| pipelinet NNTP | ja | av som standard | nei | ja | - | - |
| full verifisering under nedlasting | hver blokk | etterpå | hurtigsjekk | etterpå | etterpå | etterpå |
| utpakking under nedlasting | i strømmen, ingen volumer på disk | direkte utpakking⁴ | direkte utpakking⁴ | upålitelig⁵ | nei | nei |
| disk nødvendig for en N-GB-post | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| fullførbarhetsdom før nedlasting | blokk-eksakt | nei | helse % | nei | artikkelsjekk | nei |
| avgrenset minne (swapper aldri) | budsjettert | 9.3 GB @ 190 GB | cache-innstilling | nei | - | - |
| sjekk filen på et hvilket som helst punkt mens du laster ned | ja | nei | nei | nei | sekvensiell | nei |
| innebygd indekserer + plakatvegg | ja, nøkkelfri | nei | nei | nei | søkegrensesnitt | gruppebrowser |
| Sonarr/Radarr klar-til-bruk | SAB API + Newznab | native | native | delvis | nei | nei |
| telefonfjernkontroller (nzb360/LunaSea) | via NZBGet RPC | ja | ja | nei | nei | nei |
| watchlist auto-henting + oppgraderinger | innebygd | via *arr | via *arr | nei | Watchdog | regler |
| én enkelt selvstendig binær | ja | Python | ja | ja | .app | .exe |
| åpen kildekode | GPL⁶ | GPL | GPL | ja | betalt | betalt |
| plattformer | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | kun mac | kun win |
⁴ Direkte utpakking materialiserer fortsatt volumene først: 2× skrivinger og 2× disk. ⁵ rustnzb leverte obfuskerte volumer merket «Completed» i vår runde (utpakkingen dens henger også med RARLab unrar med mindre den deaktiveres). ⁶ GPL-3.0-or-later. Usenapp/Newsbin er enkeltplattform-kommersielle lesere med nedlasterfunksjoner; de er oppført fordi folk spør, ikke fordi de konkurrerer på fart.
Transportbevis