Quattro client, sette scenari, hardware e provider identici, esecuzioni alternate così la deriva dei provider si annulla. La metrica è il tempo per un file utilizzabile: scaricato, verificato, estratto. Comprese le prove che non vinciamo.
In questa pagina
Prima la metodologia
pipelining_requests=8 (di serie è 1, cioè senza pipeline; quella sola impostazione ha portato il suo tempo sui 190 GB da 24m24s a 19m02s), NZBGet ha ricevuto ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb la sua configurazione documentata.Scenario 1 · pulito, enorme
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tempo per file utilizzabile | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | nessuno¹ |
| GB sulla rete | 169.6 | 169.8 | 169.7 | 186.5 |
| picco RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb ha finito di spostare byte a 5m 42s dopo aver scaricato 186.5 GB (il 10% di rete in più di chiunque altro) ma non ha lasciato alcun media estratto, il suo terzo giro fallito di fila su questo post. · ² la memoria di nzbfast segue il suo budget configurato, non il job: questa prova ha usato il budget automatico predefinito e ha toccato un picco di 1.4 GB; un budget volutamente enorme da 64 GB guadagna solo il 4% (4m 22s), e limitato a 1 GB lo stesso job da 190 GB si completa comunque (vedi la scala a bassa memoria qui sotto). Nel precedente giro sulla costa est (linea ~2.4–3 Gbps) lo stesso scenario ha girato in 9m 00s contro NZBGet +30% e SABnzbd +111%. Il divario regge a ogni velocità di linea.
Scenario 2 · il divario cresce con la dimensione
Passata unica significa nessuna passata di verifica/estrazione dopo il download, quindi più grande è il job, più stacca. Esecuzioni sequenziali sulla stessa macchina:
| 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 offuscato (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (costa est) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB su un disco con 97 GB liberi (Europa) | 3m 08s | impossibile² | impossibile² |
| 190.6 GB (costa est) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² La loro impronta di picco (volumi + output estratto contemporaneamente, ~156 GB) ha superato i 97 GB liberi. La passata unica richiede 1× la dimensione del contenuto: dimezza il disco che serve, non solo il tempo.
Scenario 3 · post offuscato
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tempo per file utilizzabile | 96 s | 153 s (+59%) | 259 s (+170%) | nessun file utilizzabile³ |
| picco RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb ha scaricato in 119 s, ha segnato il job come Completato, e ha consegnato i volumi offuscati grezzi: nessuna rinomina, nessuna estrazione. nzbfast ha deoffuscato dai metadati PAR2 ed estratto nel flusso, zero blocchi riletti.
Scenario 4 · coda di tre
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| tempo totale della coda | 122 s | 136 s | 162 s | 277 s |
| linea inattiva (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Tre forme dello stesso problema: la sovrapposizione tra la fine di un job e l'inizio del successivo in nzbfast tiene la linea occupata da un capo all'altro; NZBGet non è mai inattivo ma va ~35% più lento estraendo in parallelo; SABnzbd scarica veloce, poi lascia la linea al buio per il 61% del tempo durante la post-elaborazione seriale. Nella variante di resilienza (un job con header RAR cifrati), la coda di SABnzbd si è bloccata sul job cifrato e solo 1 job su 3 è arrivato a completarsi; nzbfast lo ha parcheggiato con un messaggio chiaro e ha finito il resto.
La colonna dell'onestà
Entrambe le prove che stavano qui sono state rimisurate sulla build pubblicata e nessuna è più una sconfitta: il post store-mode danneggiato ora ci costa 30 s contro i 38 s di NZBGet, e la ricostruzione dalla sola parità si chiude in 9 s dove ne servivano 19, su una prova in cui NZBGet torna nello stesso tempo ma non consegna nulla. Lasciamo la sezione al suo posto invece di cancellarla: è qui che finiscono le nostre sconfitte, e il prossimo giro che ne troverà una la rimetterà.
Scenario 6 · affamalo di RAM
Gli stessi quattro job, ri-eseguiti con budget di memoria rigidi di 2 GB, 1 GB e 256 MB: ciò che il dimensionatore automatico sceglierebbe su una macchina da 8 GB, una da 4 GB e un NAS da 2 GB. Ogni prova ha prodotto un file corretto, pienamente verificato ed estratto; il picco RSS ha seguito il budget, non il job. Tempo per file utilizzabile, linea 10 GbE:
| Dimensione job | RAM abbondante | 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 |
Il sovrapprezzo del 20–40% sui job grandi è un artefatto del 10 GbE: i blocchi spillati costano tempo solo quando la linea supera il disco. Lo stesso job da 87 GB agli stessi budget su una linea ~2.4 Gbps ha misurato da −1% a +7%, rumore. Su una tipica connessione domestica un budget piccolo è quasi gratis a qualsiasi dimensione di job. Un profilo NAS (2 connessioni, budget 256 MB) ha finito il job da 35 GB con un picco RSS di 0.4 GB. Un NAS da 2 GB può farlo girare. Nessun altro client offre alcun tetto di memoria.
Scenario 7 · archivi dentro archivi
I post arrivano sempre più spesso annidati: un RAR dentro un RAR, un 7z infilato in un archivio in modalità store, una scala di strati, una catena di password. Questo giro valuta ciò che resta da fare all'operatore. auto significa ogni payload estratto, byte-identico, senza toccare nulla; manuale significa che il client ha dichiarato successo ma ha lasciato un archivio interno nella directory di output, da aprire da soli.
| forma | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| RAR store dentro RAR store | auto | auto | manuale | manuale |
| RAR compresso dentro RAR store | auto | auto | manuale | manuale |
| 7z dentro un RAR store | auto | auto | manuale | manuale |
| scala a 5 livelli, 6 payload | auto · 6/6 | manuale · 3/6 | manuale · 1/6 | manuale · 1/6 |
| catena di password, 3 livelli cifrati | auto · 3/3 | chiede una password | chiede una password | fallito |
| completamento automatico, tutte e dieci le forme | 8/10 | 6/10 | 2/10 | 2/10 |
Banco in loopback, corpus generato a macchina, tutti e quattro i client sulla stessa macchina, valutazione tramite hash del contenuto, così un client che rinomina il payload riceve comunque il merito. Poiché gli strati interni vengono de-annidati al volo, nzbfast tiene una sola copia da ~1.5 GB su disco dove i client «scrivi e poi estrai» ne tengono ~3 GB, e chiude queste prove in 1–2 s contro 4–8 s. Nella catena di password, la password di ogni strato viaggia in un file che lo strato sopra estrae: nzbfast la legge e sblocca tutti e tre i livelli; gli altri si fermano e aspettano che la digiti tu. Le due forme che non completa da solo sono valutate duramente di proposito: una scala a 10 livelli oltre il suo limite di profondità predefinito e un post danneggiato a tutti e tre i livelli. In entrambe recupera più payload di qualunque altro client, ma esce con codice diverso da zero invece di chiamare successo un lavoro parziale, quindi qui contano entrambe come fallimenti.
Sfide tra componenti
Estrazione e PAR2 sono codice nativo nostro, quindi li facciamo gareggiare anche da soli contro il resto del campo su corpora identici. Un tempo conta solo quando l'output è byte-identico al payload sorgente.
Contro unrar 7.23, 7-Zip, bsdtar, unar e il crate rars upstream su un Apple M3 Ultra, l'estrattore di nzbfast vince o pareggia ogni forma: 400 file piccoli in 0.13 s contro gli 0.66 s di unrar, solid 0.50 contro 0.87, cifrato 0.49 contro 0.82, un archivio RAR7 con dizionario da 128 MB 0.71 contro 0.92. Rieseguito su un M1 Ultra a 20 core e su un portatile Intel a 14 core, il risultato regge su ogni forma, e sul portatile i margini si allargano: i percorsi di decodifica paralleli scalano sui thread in più. Ogni tempo riportato ha prodotto output sha256-identico.
Contro il classico par2cmdline, il fork SIMD par2cmdline-turbo e MultiPar, nzbfast ha la verifica più veloce e la riparazione più veloce su ogni macchina testata. Desktop a 20 core: verifica pulita 0.40 s contro l'1.08 di turbo e il 3.67 del classico; riparazione di 101 blocchi danneggiati 1.26 s contro 2.61 e 7.52. Portatile a 14 core: verifica 1.26 contro 1.48, riparazione 2.57 contro 3.62. Ogni file riparato byte-identico. Una nota onesta: non creiamo PAR2 (a un downloader non serve, e quella prova appartiene a ParPar).
Quanto costa un lavoro
La promessa della passata unica riguarda il disco quanto la velocità, quindi eccola misurata invece che affermata: il massimo raggiunto dalla directory di lavoro durante le esecuzioni annidate, campionato due volte al secondo. Leggerlo una volta sola alla fine non direbbe nulla, perché un client che cancella i volumi dopo l’estrazione sembrerebbe non averli mai scritti.
| forma | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| RAR store dentro RAR store | 1538 | 1538 | 1774 | 3080 |
| livello interno compresso | 1536 | 1536 | 1674 | 3102 |
| RAR dentro RAR, profondità 2 | 1536 | 1536 | 1714 | 3076 |
| 7z avvolto in un RAR store | 1503 | 1536 | 1722 | 3102 |
Megabyte, meno è meglio. NZBGet ci eguaglia qui ed è giusto dire perché: gira con DirectUnpack e DirectWrite attivi, come configuriamo ogni concorrente, e su queste forme basta per tenere una sola copia su disco. SABnzbd ne tiene due. Il divario che resta è quello per cui la pipeline è stata costruita: non materializziamo mai i volumi, quindi il picco è il payload stesso e non il payload più l’archivio che lo trasportava.
Capacità, non micro-benchmark
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| NNTP in pipeline | sì | off di default | no | sì | - | - |
| verifica completa durante il download | ogni blocco | dopo | quick-check | dopo | dopo | dopo |
| estrazione durante il download | nel flusso, nessun volume su disco | direct unpack⁴ | direct unpack⁴ | inaffidabile⁵ | no | no |
| disco necessario per un post da N GB | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| verdetto di completabilità pre-download | esatto al blocco | no | salute % | no | controllo articoli | no |
| memoria limitata (mai swap) | a budget | 9.3 GB @ 190 GB | impostazione cache | no | - | - |
| controlla il file in qualsiasi punto durante il download | sì | no | no | no | sequenziale | no |
| indexer integrato + bacheca dei poster | sì, senza chiave | no | no | no | UI di ricerca | browser dei gruppi |
| drop-in Sonarr/Radarr | API SAB + Newznab | nativo | nativo | parziale | no | no |
| telecomandi per telefono (nzb360/LunaSea) | via RPC NZBGet | sì | sì | no | no | no |
| prelievo automatico watchlist + upgrade | integrato | via *arr | via *arr | no | Watchdog | regole |
| singolo binario autonomo | sì | Python | sì | sì | .app | .exe |
| open source | GPL⁶ | GPL | GPL | sì | a pagamento | a pagamento |
| piattaforme | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | solo mac | solo win |
⁴ Il direct unpack materializza comunque prima i volumi: 2× scritture e 2× disco. ⁵ rustnzb ha consegnato volumi offuscati segnati come «Completato» nel nostro giro (la sua estrazione inoltre si blocca con l'unrar di RARLab se non disattivata). ⁶ GPL-3.0-or-later. Usenapp/Newsbin sono lettori commerciali a piattaforma singola con funzioni di download; sono elencati perché la gente lo chiede, non perché competono sulla velocità.
Prova di trasporto