Fire klienter, syv scenarier, identisk hardware og udbydere, kørsler flettet, så udbyderdrift ophæves. Målet er tid til en brugbar fil: hentet, verificeret, udpakket. Inklusive de ben, vi ikke vinder.
På denne side
Metode først
pipelining_requests=8 (den leveres med 1, dvs. upipelinet; alene den indstilling bragte dens 190 GB-tid fra 24m24s til 19m02s), NZBGet fik ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sin dokumenterede konfiguration.Scenarie 1 · rent, kæmpe
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tid til brugbar fil | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | ingen¹ |
| GB på ledningen | 169.6 | 169.8 | 169.7 | 186.5 |
| top-RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb blev færdig med at flytte bytes på 5m 42s efter at have trukket 186.5 GB (10% mere ledning end nogen anden), men efterlod ingen udpakkede medier, dens tredje fejlede runde i træk på denne post. · ² nzbfasts hukommelse følger sit konfigurerede budget, ikke jobbet: denne runde kørte standard-auto-budgettet og toppede på 1.4 GB; et bevidst kæmpestort 64 GB-budget køber kun 4% (4m 22s), og begrænset til 1 GB fuldføres samme 190 GB-job stadig (se lav-hukommelses-stigen nedenfor). På den tidligere østkyst-runde (~2.4–3 Gbps-linje) kørte samme scenarie 9m 00s mod NZBGet +30% og SABnzbd +111%. Forspringet holder på tværs af linjehastigheder.
Scenarie 2 · forspringet vokser med størrelsen
One-pass betyder ingen verificerings-/udpakningsfase efter download, så jo større jobbet er, jo længere foran lander den. Sekventielle kørsler på samme maskine:
| Job | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX (Europa, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB obfuskeret 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 fri (Europa) | 3m 08s | kan ikke køre² | kan ikke køre² |
| 190.6 GB (østkysten) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Deres maksimale fodaftryk (volumener + udpakket output samtidig, ~156 GB) oversteg de 97 GB fri. One-pass kræver 1× indholdets størrelse: den halverer den disk, du har brug for, ikke kun tiden.
Scenarie 3 · obfuskeret post
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tid til brugbar fil | 96 s | 153 s (+59%) | 259 s (+170%) | ingen brugbar fil³ |
| top-RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb hentede på 119 s, markerede jobbet Completed, og leverede de rå obfuskerede volumener: ingen omdøbning, ingen udpakning. nzbfast deobfuskerede ud fra PAR2-metadata og udpakkede i strømmen, nul tilbagelæsningsblokke.
Scenarie 4 · kø på tre
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| kø-vægtid | 122 s | 136 s | 162 s | 277 s |
| linje i tomgang (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Tre udgaver af samme problem: nzbfasts hale-overlap holder linjen travl kant til kant; NZBGet står aldrig i tomgang, men kører ~35% langsommere, mens den udpakker samtidig; SABnzbd henter hurtigt og lader så linjen ligge mørk 61% af tiden under seriel efterbehandling. I resiliens-varianten (ét job med krypterede RAR-headers) satte SABnzbds kø sig fast på det krypterede job, og kun 1 af 3 job blev nogensinde færdige; nzbfast parkerede det med en tydelig besked og gjorde resten færdig.
Den ærlige kolonne
Begge tests, der stod her, er målt om på den udgivne build, og ingen af dem er længere et nederlag: det beskadigede store-mode-post tager os nu 30 s mod NZBGets 38 s, og rekonstruktion udelukkende fra paritet er færdig på 9 s, hvor den tog 19 s, på en test hvor NZBGet vender tilbage på samme tid, men ikke leverer noget. Vi lader afsnittet blive stående i stedet for at slette det: det er her, vores nederlag hører til, og den næste runde, der finder et, sætter det tilbage.
Scenarie 6 · sult den for RAM
De samme fire job, kørt igen ved hårde hukommelsesbudgetter på 2 GB, 1 GB og 256 MB: hvad auto-dimensioneringen ville vælge på en 8 GB-maskine, en 4 GB-maskine og en 2 GB-NAS. Hvert ben frembragte en korrekt, fuldt verificeret, udpakket fil; top-RSS fulgte budgettet, ikke jobbet. Tid til brugbar fil, 10 GbE-linje:
| Jobstørrelse | rigeligt 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 |
Præmien på 20–40% på de store job er et 10 GbE-artefakt: spillede blokke koster kun tid, når linjen løber fra disken. Samme 87 GB-job ved de samme budgetter på en ~2.4 Gbps-linje målte −1% til +7%, støj. På en typisk hjemmeforbindelse er et lille budget næsten gratis ved enhver jobstørrelse. En NAS-profil (2 forbindelser, 256 MB-budget) gjorde 35 GB-jobbet færdigt i 0.4 GB top-RSS. En 2 GB-NAS kan køre dette. Ingen anden klient tilbyder overhovedet et hukommelsesloft.
Scenarie 7 · arkiver inde i arkiver
Posts ankommer i stigende grad nestede: en RAR inde i en RAR, en 7z gemt i et store-arkiv, en stige af lag, en adgangskodekæde. Denne runde bedømmer, hvad der er tilbage til operatøren. auto betyder hver payload udpakket, byte-identisk, uden hænder; manuelt betyder, at klienten meldte succes, men efterlod et indre arkiv i output-mappen, som du selv må åbne.
| form | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| store-RAR inde i store-RAR | auto | auto | manuelt | manuelt |
| komprimeret RAR inde i store-RAR | auto | auto | manuelt | manuelt |
| 7z inde i en store-RAR | auto | auto | manuelt | manuelt |
| 5-niveauers stige, 6 payloads | auto · 6/6 | manuelt · 3/6 | manuelt · 1/6 | manuelt · 1/6 |
| adgangskodekæde, 3 krypterede niveauer | auto · 3/3 | beder om en adgangskode | beder om en adgangskode | fejlede |
| auto-fuldført, alle ti former | 8/10 | 6/10 | 2/10 | 2/10 |
Loopback-rig, maskingenereret korpus, alle fire klienter på samme maskine, bedømt efter indholdshash, så en klient, der omdøber payloaden, stadig får kredit. Fordi indre lag afnestes i farten, holder nzbfast én ~1.5 GB-kopi på disken, hvor skriv-ud-og-udpak-klienter holder ~3 GB, og bliver færdig med disse ben på 1–2 s mod 4–8 s. På adgangskodekæden leveres hvert lags adgangskode i en fil, som laget ovenover udpakker: nzbfast læser den og låser alle tre niveauer op; de andre stopper og venter på, at du taster den ind. De to former, den ikke auto-fuldfører, bedømmes hårdt med vilje: en 10-niveauers stige ud over dens standard-dybdegrænse og en post beskadiget på alle tre niveauer. På begge genvinder den flere payloads end nogen anden klient, men afslutter med en kode forskellig fra nul i stedet for at kalde et delvist job en succes, så begge tæller som fejl her.
Komponent-dueller
Udpakning og PAR2 er vores egen native kode, så vi kører dem også selvstændigt mod feltet på identiske korpusser. En tid tæller kun, når outputtet er byte-identisk med kilde-payloaden.
Mod unrar 7.23, 7-Zip, bsdtar, unar og upstream rars-craten på en Apple M3 Ultra vinder eller deler nzbfasts udpakker hver form: 400 små filer 0.13 s mod unrars 0.66 s, solid 0.50 mod 0.87, krypteret 0.49 mod 0.82, et RAR7-arkiv med 128 MB-ordbog 0.71 mod 0.92. Kørt igen på en 20-kernes M1 Ultra og på en 14-kernes Intel-laptop holder resultatet på hver form, og på laptoppen bliver marginerne bredere: de parallelle afkodningsstier skalerer ind i de ekstra tråde. Hver rapporteret tid gav sha256-identisk output.
Mod klassisk par2cmdline, SIMD-forken par2cmdline-turbo og MultiPar har nzbfast den hurtigste verificering og den hurtigste reparation på hver benchet maskine. 20-kernes desktop: ren verificering 0.40 s mod turboens 1.08 og klassikerens 3.67; reparation af 101 beskadigede blokke 1.26 s mod 2.61 og 7.52. 14-kernes laptop: verificering 1.26 mod 1.48, reparation 2.57 mod 3.62. Hver repareret fil byte-identisk. En ærlig note: vi opretter ikke PAR2 (en downloader behøver det ikke, og ParPar ejer det ben).
Hvad et job koster
Løftet om én gennemgang handler lige så meget om disk som om hastighed, så her er det målt i stedet for påstået: det højeste arbejdsmappen nåede under de indlejrede kørsler, aflæst to gange i sekundet. En enkelt aflæsning til sidst ville intet sige, for en klient, der sletter sine volumener efter udpakning, ville se ud som om den aldrig havde skrevet dem.
| form | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| store-RAR i store-RAR | 1538 | 1538 | 1774 | 3080 |
| komprimeret 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øjde med os her, og det er værd at sige hvorfor: den kører med DirectUnpack og DirectWrite slået til, sådan som vi konfigurerer enhver konkurrent, og på disse former er det nok til én kopi på disken. SABnzbd holder to. Forskellen, der er tilbage, er den, pipelinen blev bygget til: vi materialiserer slet ikke volumenerne, så toppen er nyttelasten selv frem for nyttelasten plus arkivet, der bar den.
Formåen, ikke mikro-benchmarks
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| pipelinet NNTP | ja | fra som standard | nej | ja | - | - |
| fuld verificering under download | hver blok | efter | hurtigtjek | efter | efter | efter |
| udpak under download | i strømmen, ingen volumener på disk | direkte udpakning⁴ | direkte udpakning⁴ | upålidelig⁵ | nej | nej |
| disk krævet til en N-GB-post | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| fuldførbarheds-dom før download | blok-eksakt | nej | sundhed % | nej | artikeltjek | nej |
| begrænset hukommelse (swapper aldrig) | budgetteret | 9.3 GB @ 190 GB | cache-indstilling | nej | - | - |
| tjek filen på ethvert punkt under download | ja | nej | nej | nej | sekventiel | nej |
| indbygget indexer + postervæg | ja, nøglefri | nej | nej | nej | søge-UI | gruppebrowser |
| Sonarr/Radarr drop-in | SAB API + Newznab | native | native | delvis | nej | nej |
| telefon-fjernbetjeninger (nzb360/LunaSea) | via NZBGet-RPC | ja | ja | nej | nej | nej |
| overvågningslistens auto-hent + opgraderinger | indbygget | via *arr | via *arr | nej | Watchdog | regler |
| én selvstændig binær | ja | Python | ja | ja | .app | .exe |
| open source | GPL⁶ | GPL | GPL | ja | betalt | betalt |
| platforme | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | kun mac | kun win |
⁴ Direkte udpakning materialiserer stadig volumenerne først: 2× skrivninger og 2× disk. ⁵ rustnzb leverede obfuskerede volumener markeret "Completed" i vores runde (dens udpakning hænger også med RARLab-unrar, medmindre den er slået fra). ⁶ GPL-3.0-or-later. Usenapp/Newsbin er kommercielle læsere til én platform med downloader-funktioner; de er med, fordi folk spørger, ikke fordi de konkurrerer på hastighed.
Transportbevis