Patru clienți, șapte scenarii, hardware și provideri identici, rulări intercalate ca variația providerilor să se anuleze. Măsura este timpul până la un fișier utilizabil: descărcat, verificat, extras. Include probele pe care nu le câștigăm.
Pe această pagină
Mai întâi metodologia
pipelining_requests=8 (vine cu 1, adică fără pipelining; doar acea setare i-a redus timpul pe 190 GB de la 24m24s la 19m02s), NZBGet a primit ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb configurația sa documentată.Scenariul 1 · curat, uriaș
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| timp până la fișierul utilizabil | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | none¹ |
| GB pe fir | 169.6 | 169.8 | 169.7 | 186.5 |
| RSS de vârf | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb a terminat de mutat octeții la 5m 42s, după ce a tras 186.5 GB (cu 10% mai mult trafic decât oricine), dar nu a lăsat niciun fișier media extras, a treia lui rundă eșuată la rând pe această postare. · ² memoria nzbfast urmează bugetul configurat, nu jobul: această rundă a rulat pe bugetul auto implicit și a atins un vârf de 1.4 GB; un buget uriaș de 64 GB, ales dinadins, aduce doar 4% (4m 22s), iar limitat la 1 GB, același job de 190 GB tot se finalizează (vezi scara de memorie redusă mai jos). În runda anterioară de pe Coasta de Est (linie de ~2.4–3 Gbps), același scenariu a rulat 9m 00s față de NZBGet +30% și SABnzbd +111%. Diferența se menține la diferite viteze de linie.
Scenariul 2 · diferența crește cu dimensiunea
O singură trecere înseamnă fără trecere de verificare/dezarhivare după descărcare, așa că, cu cât jobul e mai mare, cu atât aterizează mai în față. Rulări secvențiale pe aceeași mașină:
| Job | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX (Europa, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB 4K obfuscat (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (Coasta de Est) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB pe un disc cu 97 GB liberi (Europa) | 3m 08s | cannot run² | cannot run² |
| 190.6 GB (Coasta de Est) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Amprenta lor de vârf (volume + ieșire dezarhivată simultan, ~156 GB) a depășit cei 97 GB liberi. O singură trecere are nevoie de 1× dimensiunea conținutului: înjumătățește discul de care ai nevoie, nu doar timpul.
Scenariul 3 · postare obfuscată
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| timp până la fișierul utilizabil | 96 s | 153 s (+59%) | 259 s (+170%) | no usable file³ |
| RSS de vârf | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb a descărcat în 119 s, a marcat jobul Completed, și a livrat volumele obfuscate brute: fără redenumire, fără extragere. nzbfast a deobfuscat din metadatele PAR2 și a extras în flux, zero blocuri citite înapoi.
Scenariul 4 · coadă de trei
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| timp real al cozii | 122 s | 136 s | 162 s | 277 s |
| linie inactivă (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Trei forme ale aceleiași probleme: suprapunerea cozii nzbfast ține linia ocupată de la un capăt la altul; NZBGet nu stă niciodată inactiv, dar rulează cu ~35% mai lent în timp ce dezarhivează concurent; SABnzbd descarcă rapid, apoi lasă linia întunecată 61% din timp în timpul post-procesării seriale. În varianta de reziliență (un job cu antete RAR criptate), coada SABnzbd s-a înțepenit pe jobul criptat și doar 1 din 3 joburi s-a finalizat vreodată; nzbfast l-a parcat cu un mesaj clar și a terminat restul.
Coloana onestă
Ambele probe care stăteau aici au fost remăsurate pe versiunea publicată și niciuna nu mai este o pierdere: postarea store-mode deteriorată ne ia acum 30 s față de 38 s la NZBGet, iar reconstrucția doar din paritate se încheie în 9 s față de 19 s, pe o probă unde NZBGet revine în același timp dar nu livrează nimic. Lăsăm secțiunea aici în loc să o ștergem: aici ajung pierderile noastre, iar următoarea rundă care găsește una o va pune la loc.
Scenariul 6 · înfometează-l de RAM
Aceleași patru joburi, rerulate la bugete de memorie stricte de 2 GB, 1 GB și 256 MB: ce ar alege dimensionatorul automat pe o mașină de 8 GB, una de 4 GB și un NAS de 2 GB. Fiecare probă a produs un fișier corect, complet verificat și extras; RSS de vârf a urmărit bugetul, nu jobul. Timp până la fișierul utilizabil, linie de 10 GbE:
| Dimensiunea jobului | suficient RAM | buget 2 GB | buget 1 GB | buget 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 |
Suplimentul de 20–40% la joburile mari este un artefact al 10 GbE: blocurile trecute pe disc costă timp doar când linia întrece discul. Același job de 87 GB la aceleași bugete pe o linie de ~2.4 Gbps a măsurat −1% până la +7%, zgomot. Pe o conexiune casnică tipică, un buget mic este aproape gratuit la orice dimensiune de job. Un profil de NAS (2 conexiuni, buget de 256 MB) a terminat jobul de 35 GB cu 0.4 GB RSS de vârf. Un NAS de 2 GB poate rula asta. Niciun alt client nu oferă vreun plafon de memorie.
Scenariul 7 · arhive în arhive
Postările sosesc tot mai des imbricate: un RAR într-un RAR, un 7z vârât într-o arhivă store, o scară de straturi, un lanț de parole. Această rundă notează ce rămâne pe seama operatorului. auto înseamnă fiecare payload extras, identic la octet, fără nicio intervenție; manual înseamnă că clientul a raportat succes, dar a lăsat o arhivă interioară în directorul de ieșire, să o deschizi tu.
| forma | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| RAR store într-un RAR store | auto | auto | manual | manual |
| RAR comprimat într-un RAR store | auto | auto | manual | manual |
| 7z într-un RAR store | auto | auto | manual | manual |
| scară pe 5 niveluri, 6 payload-uri | auto · 6/6 | manual · 3/6 | manual · 1/6 | manual · 1/6 |
| lanț de parole, 3 niveluri criptate | auto · 3/3 | cere o parolă | cere o parolă | a eșuat |
| auto-finalizare, toate cele zece forme | 8/10 | 6/10 | 2/10 | 2/10 |
Montaj loopback, corpus generat de mașină, toți cei patru clienți pe aceeași mașină, notare după hash-ul conținutului, așa că un client care redenumește payload-ul tot primește credit. Pentru că straturile interioare sunt dezimbricate din mers, nzbfast ține pe disc o singură copie de ~1.5 GB, acolo unde clienții care scriu pe disc și despachetează țin ~3 GB, și termină aceste probe în 1–2 s față de 4–8 s. La lanțul de parole, parola fiecărui strat vine într-un fișier pe care îl extrage stratul de deasupra: nzbfast îl citește și deblochează toate cele trei niveluri; ceilalți se opresc și așteaptă să o tastezi tu. Cele două forme pe care nu le auto-finalizează sunt notate dinadins cu asprime: o scară pe 10 niveluri dincolo de plafonul implicit de adâncime și o postare deteriorată la toate cele trei niveluri. Pe ambele recuperează mai multe payload-uri decât oricare alt client, dar iese cu cod diferit de zero în loc să numească succes un job parțial, așa că ambele contează aici ca eșecuri.
Dueluri pe componente
Extragerea și PAR2 sunt cod nativ propriu, așa că le punem și separat în cursă cu restul terenului, pe corpusuri identice. Un timp contează doar când ieșirea este identică la octet cu payload-ul sursă.
Față de unrar 7.23, 7-Zip, bsdtar, unar și crate-ul rars din amonte, pe un Apple M3 Ultra, extractorul nzbfast câștigă sau egalează fiecare formă: 400 de fișiere mici în 0.13 s față de 0.66 s la unrar, solid 0.50 vs 0.87, criptat 0.49 vs 0.82, o arhivă RAR7 cu dicționar de 128 MB 0.71 vs 0.92. Rerulate pe un M1 Ultra cu 20 de nuclee și pe un laptop Intel cu 14 nuclee, rezultatul se menține pe fiecare formă, iar pe laptop marjele se lărgesc: căile de decodare paralelă scalează în firele suplimentare. Fiecare timp raportat a produs ieșire identică sha256.
Față de clasicul par2cmdline, de fork-ul SIMD par2cmdline-turbo și de MultiPar, nzbfast are cea mai rapidă verificare și cea mai rapidă reparare pe fiecare mașină testată. Desktop cu 20 de nuclee: verificare curată 0.40 s față de 1.08 la turbo și 3.67 la clasic; repararea a 101 blocuri deteriorate 1.26 s vs 2.61 și 7.52. Laptop cu 14 nuclee: verificare 1.26 vs 1.48, reparare 2.57 vs 3.62. Fiecare fișier reparat, identic la octet. O notă onestă: nu creăm PAR2 (un program de descărcare nu are nevoie, iar proba aceea îi aparține lui ParPar).
Cât costă o sarcină
Promisiunea unei singure treceri ține de disc la fel de mult ca de viteză, așa că iat-o măsurată în loc de afirmată: maximul atins de directorul de lucru în timpul rulărilor imbricate, eșantionat de două ori pe secundă. O singură citire la final n-ar spune nimic, pentru că un client care își șterge volumele după extragere ar părea că nu le-a scris niciodată.
| formă | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| RAR store în RAR store | 1538 | 1538 | 1774 | 3080 |
| strat interior comprimat | 1536 | 1536 | 1674 | 3102 |
| RAR în RAR, adâncime 2 | 1536 | 1536 | 1714 | 3076 |
| 7z învelit într-un RAR store | 1503 | 1536 | 1722 | 3102 |
Megaocteți, mai puțin e mai bine. NZBGet ne egalează aici și merită spus de ce: rulează cu DirectUnpack și DirectWrite activate, așa cum configurăm fiecare concurent, iar pe aceste forme e suficient pentru o singură copie pe disc. SABnzbd ține două. Diferența rămasă este cea pentru care a fost construită conducta: noi nu materializăm deloc volumele, deci vârful este chiar conținutul, nu conținutul plus arhiva care l-a purtat.
Capabilitate, nu micro-benchmark-uri
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| NNTP cu pipelining | yes | off by default | no | yes | - | - |
| verificare completă în timpul descărcării | every block | after | quick-check | after | after | after |
| extragere în timpul descărcării | in-stream, no volumes on disk | direct unpack⁴ | direct unpack⁴ | unreliable⁵ | no | no |
| disc necesar pentru o postare de N GB | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| verdict de completabilitate înainte de descărcare | block-exact | no | health % | no | article check | no |
| memorie limitată (fără swap niciodată) | budgeted | 9.3 GB @ 190 GB | cache setting | no | - | - |
| verifică fișierul în orice punct în timpul descărcării | yes | no | no | no | sequential | no |
| indexer integrat + perete de postere | yes, keyless | no | no | no | search UI | group browser |
| drop-in Sonarr/Radarr | SAB API + Newznab | native | native | partial | no | no |
| telecomenzi de telefon (nzb360/LunaSea) | via NZBGet RPC | yes | yes | no | no | no |
| preluare automată watchlist + upgrade-uri | built in | via *arr | via *arr | no | Watchdog | rules |
| binar unic de sine stătător | yes | Python | yes | yes | .app | .exe |
| open source | GPL⁶ | GPL | GPL | yes | paid | paid |
| platforme | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | mac only | win only |
⁴ Dezarhivarea directă tot materializează întâi volumele: 2× scrieri și 2× disc. ⁵ rustnzb a livrat volume obfuscate marcate „Completed” în runda noastră (dezarhivarea sa se și blochează cu unrar RARLab dacă nu e dezactivată). ⁶ GPL-3.0-or-later. Usenapp/Newsbin sunt cititoare comerciale mono-platformă cu funcții de descărcare; sunt listate pentru că oamenii întreabă, nu pentru că ar concura la viteză.
Dovada de transport