Vier clients, zeven scenario's, identieke hardware en providers, runs afwisselend uitgevoerd zodat providerdrift wegvalt. De maatstaf is tijd tot een bruikbaar bestand: gedownload, geverifieerd, uitgepakt. Inclusief de legs die we niet winnen.
Op deze pagina
Eerst de methodologie
pipelining_requests=8 (standaard staat die op 1, dus ongepipelined; alleen die instelling al bracht z'n 190 GB-tijd terug van 24m24s naar 19m02s), NZBGet kreeg ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb z'n gedocumenteerde config.Scenario 1 · schoon, enorm
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tijd tot bruikbaar bestand | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | geen¹ |
| GB over de lijn | 169.6 | 169.8 | 169.7 | 186.5 |
| piek-RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb was op 5m 42s klaar met bytes verplaatsen na het binnenhalen van 186.5 GB (10% meer over de lijn dan wie dan ook) maar liet geen uitgepakte media achter, z'n derde mislukte ronde op rij op deze post. · ² het geheugen van nzbfast volgt z'n ingestelde budget, niet de taak: deze leg draaide het standaard auto-budget en piekte op 1.4 GB; een bewust reusachtig budget van 64 GB levert maar 4% op (4m 22s), en begrensd op 1 GB voltooit dezelfde taak van 190 GB nog steeds (zie de low-memory-ladder hieronder). In de eerdere oostkust-VS-ronde (~2.4–3 Gbps-lijn) draaide hetzelfde scenario in 9m 00s vs NZBGet +30% en SABnzbd +111%. De kloof houdt stand over verschillende lijnsnelheden.
Scenario 2 · de kloof groeit met de grootte
One-pass betekent geen aparte verificatie-/uitpakpass na de download, dus hoe groter de taak, hoe verder hij vooruit ligt. Sequentiële runs op dezelfde machine:
| Taak | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX (Europa, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB geobfusceerd 4K (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (oostkust VS) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB op een schijf met 97 GB vrij (Europa) | 3m 08s | kan niet draaien² | kan niet draaien² |
| 190.6 GB (oostkust VS) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Hun piekvoetafdruk (volumes + uitgepakte uitvoer tegelijk, ~156 GB) overschreed de 97 GB vrij. One-pass heeft 1× de contentgrootte nodig: het halveert de schijf die je nodig hebt, niet alleen de tijd.
Scenario 3 · geobfusceerde post
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tijd tot bruikbaar bestand | 96 s | 153 s (+59%) | 259 s (+170%) | geen bruikbaar bestand³ |
| piek-RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb downloadde in 119 s, markeerde de taak als Completed, en leverde de rauwe geobfusceerde volumes: geen hernoeming, geen uitpakken. nzbfast deobfusceerde vanuit PAR2-metadata en pakte in-stream uit, nul terug te lezen blokken.
Scenario 4 · wachtrij van drie
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| tijd om de wachtrij af te ronden | 122 s | 136 s | 162 s | 277 s |
| lijn inactief (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Drie vormen van hetzelfde probleem: de staartoverlap van nzbfast houdt de lijn van rand tot rand bezig; NZBGet valt nooit stil maar draait ~35% trager doordat het tegelijk uitpakt; SABnzbd downloadt snel en laat de lijn daarna 61% van de tijd donker tijdens seriële nabewerking. In de veerkrachtvariant (één taak met versleutelde RAR-headers) liep de wachtrij van SABnzbd vast op de versleutelde taak en werd slechts 1 van de 3 taken ooit voltooid; nzbfast parkeerde hem met een duidelijke melding en maakte de rest af.
De eerlijke kolom
Beide runs die hier stonden zijn opnieuw gemeten op de uitgebrachte build en geen van beide is nog een verlies: de beschadigde store-mode post kost ons nu 30 s tegen 38 s voor NZBGet, en reconstructie uit alleen pariteit is klaar in 9 s waar het 19 s duurde, op een run waar NZBGet in dezelfde tijd terugkeert maar niets aflevert. We laten de sectie staan in plaats van hem te verwijderen: hier komen onze verliezen, en de volgende ronde die er een vindt zet hem terug.
Scenario 6 · verhonger het van RAM
Dezelfde vier taken, opnieuw gedraaid bij harde geheugenbudgetten van 2 GB, 1 GB en 256 MB: wat de auto-sizer zou kiezen op een 8 GB-machine, een 4 GB-machine en een 2 GB-NAS. Elke leg leverde een correct, volledig geverifieerd, uitgepakt bestand; piek-RSS volgde het budget, niet de taak. Tijd tot bruikbaar bestand, 10 GbE-lijn:
| Taakgrootte | ruim RAM | budget 2 GB | budget 1 GB | budget 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 |
De opslag van 20–40% op de grote taken is een 10 GbE-artefact: gespilde blokken kosten alleen tijd als de lijn de schijf voorbijstreeft. Dezelfde taak van 87 GB bij dezelfde budgetten op een ~2.4 Gbps-lijn mat −1% tot +7%, ruis. Op een doorsnee thuisverbinding is een klein budget bij elke taakgrootte vrijwel gratis. Een NAS-profiel (2 verbindingen, budget 256 MB) rondde de taak van 35 GB af in 0.4 GB piek-RSS. Een 2 GB-NAS kan dit draaien. Geen enkele andere client biedt überhaupt een geheugenplafond.
Scenario 7 · archieven in archieven
Posts komen steeds vaker genest binnen: een RAR in een RAR, een 7z weggestopt in een store-archief, een ladder van lagen, een wachtwoordketen. Deze ronde beoordeelt wat er voor de operator overblijft. auto betekent elke payload uitgepakt, byte-identiek, zonder ook maar iets te doen; handmatig betekent dat de client succes meldde maar een binnenste archief in de uitvoermap liet liggen om zelf te openen.
| vorm | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| store-RAR in een store-RAR | auto | auto | handmatig | handmatig |
| gecomprimeerde RAR in een store-RAR | auto | auto | handmatig | handmatig |
| 7z in een store-RAR | auto | auto | handmatig | handmatig |
| ladder van 5 niveaus, 6 payloads | auto · 6/6 | handmatig · 3/6 | handmatig · 1/6 | handmatig · 1/6 |
| wachtwoordketen, 3 versleutelde niveaus | auto · 3/3 | vraagt om een wachtwoord | vraagt om een wachtwoord | mislukt |
| automatisch voltooid, alle tien vormen | 8/10 | 6/10 | 2/10 | 2/10 |
Loopback-rig, machinaal gegenereerd corpus, alle vier de clients op dezelfde machine, beoordeeld op content-hash, dus een client die de payload hernoemt krijgt gewoon de punten. Doordat binnenste lagen on-the-fly worden ontnest, houdt nzbfast één kopie van ~1.5 GB op schijf vast waar wegschrijf-en-uitpak-clients ~3 GB vasthouden, en maakt het deze legs af in 1–2 s tegenover 4–8 s. Bij de wachtwoordketen zit het wachtwoord van elke laag in een bestand dat de laag erboven uitpakt: nzbfast leest het en ontgrendelt alle drie de niveaus; de anderen stoppen en wachten tot jij het intypt. De twee vormen die hij niet automatisch afmaakt worden met opzet streng beoordeeld: een ladder van 10 niveaus voorbij z'n standaard dieptelimiet en een post die op alle drie de niveaus beschadigd is. Op beide redt hij meer payloads dan welke andere client ook, maar hij eindigt met een niet-nul exitcode in plaats van een half werk succes te noemen, dus beide tellen hier als mislukkingen.
Componentduels
Uitpakken en PAR2 zijn onze eigen native code, dus we racen ze ook los tegen het veld op identieke corpora. Een tijd telt alleen als de uitvoer byte-identiek is aan de bron-payload.
Tegen unrar 7.23, 7-Zip, bsdtar, unar en de upstream rars-crate op een Apple M3 Ultra wint of evenaart de uitpakker van nzbfast elke vorm: 400 kleine bestanden in 0.13 s tegenover de 0.66 s van unrar, solid 0.50 vs 0.87, versleuteld 0.49 vs 0.82, een RAR7-archief met 128 MB-woordenboek 0.71 vs 0.92. Opnieuw gedraaid op een M1 Ultra met 20 cores en op een Intel-laptop met 14 cores houdt het resultaat stand bij elke vorm, en op de laptop worden de marges groter: de parallelle decodeerpaden schalen mee met de extra threads. Elke gerapporteerde tijd leverde sha256-identieke uitvoer op.
Tegen het klassieke par2cmdline, de SIMD-fork par2cmdline-turbo en MultiPar heeft nzbfast op elke gebenchte machine de snelste verificatie en het snelste herstel. Desktop met 20 cores: schone verificatie 0.40 s tegenover de 1.08 van turbo en de 3.67 van de klassieker; herstel van 101 beschadigde blokken 1.26 s vs 2.61 en 7.52. Laptop met 14 cores: verificatie 1.26 vs 1.48, herstel 2.57 vs 3.62. Elk hersteld bestand byte-identiek. Eén eerlijke kanttekening: we maken geen PAR2 aan (een downloader heeft dat niet nodig, en die leg is van ParPar).
Wat een klus je kost
De belofte van één ronde gaat net zo goed over schijfruimte als over snelheid, dus hier is hij gemeten in plaats van beweerd: het hoogste punt dat de werkmap bereikte tijdens de geneste runs, twee keer per seconde bemonsterd. Eén keer aflezen aan het eind zou niets zeggen, want een client die zijn volumes na het uitpakken verwijdert zou lijken alsof hij ze nooit geschreven heeft.
| vorm | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| store-RAR in store-RAR | 1538 | 1538 | 1774 | 3080 |
| gecomprimeerde binnenlaag | 1536 | 1536 | 1674 | 3102 |
| RAR in RAR, diepte 2 | 1536 | 1536 | 1714 | 3076 |
| 7z verpakt in een store-RAR | 1503 | 1536 | 1722 | 3102 |
Megabytes, lager is beter. NZBGet komt hier gelijk met ons en het is de moeite waard te zeggen waarom: het draait met DirectUnpack en DirectWrite aan, zoals we elke concurrent instellen, en op deze vormen is dat genoeg voor één kopie op schijf. SABnzbd houdt er twee. Het verschil dat overblijft is waar de pijplijn voor gebouwd is: wij materialiseren de volumes helemaal niet, dus de piek is de payload zelf en niet de payload plus het archief dat hem droeg.
Capaciteit, geen micro-benchmarks
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| gepipelinede NNTP | ja | standaard uit | nee | ja | - | - |
| volledige verificatie tijdens download | elk blok | na afloop | quick-check | na afloop | na afloop | na afloop |
| uitpakken tijdens download | in-stream, geen volumes op schijf | direct unpack⁴ | direct unpack⁴ | onbetrouwbaar⁵ | nee | nee |
| schijf nodig voor een N-GB-post | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| completabiliteitsoordeel vóór download | blok-exact | nee | gezondheids-% | nee | artikelcheck | nee |
| begrensd geheugen (nooit swappen) | gebudgetteerd | 9.3 GB @ 190 GB | cache-instelling | nee | - | - |
| het bestand op elk punt controleren tijdens het downloaden | ja | nee | nee | nee | sequentieel | nee |
| ingebouwde indexer + posterwall | ja, sleutelloos | nee | nee | nee | zoek-UI | groepsbrowser |
| Sonarr/Radarr drop-in | SAB API + Newznab | native | native | gedeeltelijk | nee | nee |
| telefoon-remotes (nzb360/LunaSea) | via NZBGet RPC | ja | ja | nee | nee | nee |
| watchlist auto-grab + upgrades | ingebouwd | via *arr | via *arr | nee | Watchdog | regels |
| één op zichzelf staande binary | ja | Python | ja | ja | .app | .exe |
| open source | GPL⁶ | GPL | GPL | ja | betaald | betaald |
| platforms | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | alleen mac | alleen win |
⁴ Direct unpack materialiseert de volumes eerst alsnog: 2× schrijven en 2× schijf. ⁵ rustnzb leverde geobfusceerde volumes gemarkeerd als "Completed" in onze ronde (z'n uitpakken loopt bovendien vast met RARLab-unrar tenzij uitgeschakeld). ⁶ GPL-3.0-or-later. Usenapp/Newsbin zijn commerciële readers voor één platform met downloaderfuncties; ze staan erbij omdat mensen ernaar vragen, niet omdat ze op snelheid meedoen.
Transportbewijs