Quatro clientes, sete cenários, hardware e provedores idênticos, execuções intercaladas para que a deriva dos provedores se cancele. A métrica é tempo até um arquivo utilizável: baixado, verificado, extraído. Inclui os legs que não vencemos.
Nesta página
Metodologia primeiro
pipelining_requests=8 (ele vem com 1, ou seja, sem pipeline; só esse ajuste tirou seu tempo de 190 GB de 24m24s para 19m02s), o NZBGet recebeu ArticleCache/DirectWrite/DirectUnpack/ParQuick, o rustnzb sua configuração documentada.Cenário 1 · limpo, enorme
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tempo até arquivo utilizável | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | nenhum¹ |
| GB na linha | 169.6 | 169.8 | 169.7 | 186.5 |
| pico de RSS | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ o rustnzb terminou de mover bytes aos 5m 42s tendo puxado 186,5 GB (10% mais tráfego que qualquer um), mas não deixou nenhuma mídia extraída, sua terceira rodada seguida fracassada nesta publicação. · ² a memória do nzbfast segue seu orçamento configurado, não o trabalho: esta rodada rodou o orçamento automático padrão e teve pico de 1,4 GB; um orçamento deliberadamente enorme de 64 GB compra só 4% (4m 22s), e limitado a 1 GB o mesmo trabalho de 190 GB ainda termina (veja a escada de pouca memória abaixo). Na rodada anterior da costa leste (linha de ~2,4–3 Gbps), o mesmo cenário rodou 9m 00s vs NZBGet +30% e SABnzbd +111%. A diferença se mantém entre velocidades de linha.
Cenário 2 · a diferença cresce com o tamanho
Passagem única significa que não há passagem de verificação/extração após o download, então quanto maior o trabalho, mais à frente ele chega. Execuções sequenciais na mesma máquina:
| Trabalho | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| REMUX de 7,4 GB (Europa, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 4K ofuscado de 35 GB (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 4K de 87 GB (costa leste) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB em um disco com 97 GB livres (Europa) | 3m 08s | não roda² | não roda² |
| 190,6 GB (costa leste) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² A pegada de pico deles (volumes + saída extraída simultaneamente, ~156 GB) excedeu os 97 GB livres. A passagem única precisa de 1× o tamanho do conteúdo: ela reduz à metade o disco necessário, não só o tempo.
Cenário 3 · publicação ofuscada
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tempo até arquivo utilizável | 96 s | 153 s (+59%) | 259 s (+170%) | nenhum arquivo utilizável³ |
| pico de RSS | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ o rustnzb baixou em 119 s, marcou o trabalho como Concluído, e entregou os volumes ofuscados crus: sem renomear, sem extrair. O nzbfast desofuscou a partir dos metadados PAR2 e extraiu no fluxo, zero blocos lidos de volta.
Cenário 4 · fila de três
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| tempo de parede da fila | 122 s | 136 s | 162 s | 277 s |
| linha ociosa (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Três formas do mesmo problema: a sobreposição de cauda do nzbfast mantém a linha ocupada de ponta a ponta; o NZBGet nunca fica ocioso, mas roda ~35% mais lento enquanto extrai concorrentemente; o SABnzbd baixa rápido e depois deixa a linha no escuro 61% do tempo durante o pós-processamento serial. Na variante de resiliência (um trabalho com cabeçalhos RAR criptografados), a fila do SABnzbd emperrou no trabalho criptografado e apenas 1 de 3 trabalhos chegou a concluir; o nzbfast o estacionou com uma mensagem clara e terminou o resto.
A coluna honesta
As duas provas que ficavam aqui foram remedidas na versão publicada e nenhuma é mais uma derrota: o post store-mode danificado agora nos leva 30 s contra os 38 s do NZBGet, e a reconstrução só por paridade termina em 9 s onde levava 19 s, numa prova em que o NZBGet responde no mesmo tempo mas não entrega nada. Deixamos a seção aqui em vez de apagá-la: é aqui que vão as nossas derrotas, e a próxima rodada que encontrar uma vai recolocá-la.
Cenário 6 · prive-o de RAM
Os mesmos quatro trabalhos, refeitos em orçamentos rígidos de memória de 2 GB, 1 GB e 256 MB: o que o autodimensionador escolheria em uma máquina de 8 GB, uma de 4 GB e um NAS de 2 GB. Cada leg produziu um arquivo correto, totalmente verificado e extraído; o pico de RSS acompanhou o orçamento, não o trabalho. Tempo até arquivo utilizável, linha de 10 GbE:
| Tamanho do trabalho | RAM de sobra | orçamento de 2 GB | orçamento de 1 GB | orçamento de 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 |
O ágio de 20–40% nos trabalhos grandes é um artefato de 10 GbE: blocos que dão spill só custam tempo quando a linha supera o disco. O mesmo trabalho de 87 GB nos mesmos orçamentos em uma linha de ~2,4 Gbps mediu −1% a +7%, ruído. Em uma conexão doméstica típica, um orçamento pequeno é quase de graça em qualquer tamanho de trabalho. Um perfil de NAS (2 conexões, orçamento de 256 MB) terminou o trabalho de 35 GB em 0,4 GB de pico de RSS. Um NAS de 2 GB consegue rodar isto. Nenhum outro cliente oferece qualquer teto de memória.
Cenário 7 · arquivos dentro de arquivos
As publicações chegam cada vez mais aninhadas: um RAR dentro de um RAR, um 7z enfiado em um arquivo em modo armazenamento, uma escada de camadas, uma cadeia de senhas. Esta rodada avalia o que sobra para o operador. auto significa cada payload extraído, byte-idêntico, sem pôr a mão; manual significa que o cliente informou sucesso, mas deixou um arquivo interno parado no diretório de saída para você mesmo abrir.
| forma | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| RAR em modo armazenamento dentro de RAR em modo armazenamento | auto | auto | manual | manual |
| RAR comprimido dentro de RAR em modo armazenamento | auto | auto | manual | manual |
| 7z dentro de um RAR em modo armazenamento | auto | auto | manual | manual |
| escada de 5 níveis, 6 payloads | auto · 6/6 | manual · 3/6 | manual · 1/6 | manual · 1/6 |
| cadeia de senhas, 3 níveis criptografados | auto · 3/3 | pede uma senha | pede uma senha | falhou |
| conclusão automática, todas as dez formas | 8/10 | 6/10 | 2/10 | 2/10 |
Bancada em loopback, corpus gerado por máquina, os quatro clientes na mesma máquina, avaliação por hash de conteúdo, de modo que um cliente que renomeia o payload ainda recebe crédito. Como as camadas internas são desaninhadas em pleno voo, o nzbfast mantém uma única cópia de ~1,5 GB no disco onde os clientes que gravam e desempacotam mantêm ~3 GB, e termina esses legs em 1–2 s contra 4–8 s. Na cadeia de senhas, a senha de cada camada vem em um arquivo que a camada acima extrai: o nzbfast a lê e desbloqueia os três níveis; os outros param e esperam você digitá-la. As duas formas que ele não conclui automaticamente são avaliadas com rigor de propósito: uma escada de 10 níveis além do seu limite de profundidade padrão e uma publicação danificada nos três níveis. Em ambas ele recupera mais payloads que qualquer outro cliente, mas sai com código diferente de zero em vez de chamar um trabalho parcial de sucesso, então as duas contam como falhas aqui.
Duelos de componentes
A extração e o PAR2 são código nativo nosso, então também os corremos isoladamente contra o campo em corpora idênticos. Um tempo só conta quando a saída é byte-idêntica ao payload de origem.
Contra unrar 7.23, 7-Zip, bsdtar, unar e o crate rars original em um Apple M3 Ultra, o extrator do nzbfast vence ou empata em todas as formas: 400 arquivos pequenos em 0,13 s contra os 0,66 s do unrar, sólido 0,50 vs 0,87, criptografado 0,49 vs 0,82, um arquivo RAR7 com dicionário de 128 MB 0,71 vs 0,92. Refeito em um M1 Ultra de 20 núcleos e em um laptop Intel de 14 núcleos, o resultado se mantém em todas as formas, e no laptop as margens aumentam: os caminhos de decodificação paralela escalam para os threads extras. Cada tempo relatado produziu saída sha256-idêntica.
Contra o par2cmdline clássico, o fork SIMD par2cmdline-turbo e o MultiPar, o nzbfast tem a verificação mais rápida e o reparo mais rápido em todas as máquinas testadas. Desktop de 20 núcleos: verificação limpa em 0,40 s contra 1,08 do turbo e 3,67 do clássico; reparo de 101 blocos danificados em 1,26 s vs 2,61 e 7,52. Laptop de 14 núcleos: verificação 1,26 vs 1,48, reparo 2,57 vs 3,62. Cada arquivo reparado byte-idêntico. Uma nota honesta: não criamos PAR2 (um baixador não precisa, e o ParPar é dono desse leg).
O que uma tarefa custa
A promessa de uma única passagem é tanto sobre disco quanto sobre velocidade, então aqui está medida em vez de afirmada: o máximo que o diretório de trabalho atingiu durante as execuções aninhadas, amostrado duas vezes por segundo. Ler uma única vez no fim não diria nada, porque um cliente que apaga os volumes após extrair pareceria nunca tê-los escrito.
| forma | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| RAR store dentro de RAR store | 1538 | 1538 | 1774 | 3080 |
| camada interna comprimida | 1536 | 1536 | 1674 | 3102 |
| RAR dentro de RAR, profundidade 2 | 1536 | 1536 | 1714 | 3076 |
| 7z embrulhado num RAR store | 1503 | 1536 | 1722 | 3102 |
Megabytes, menos é melhor. O NZBGet nos iguala aqui e vale dizer por quê: está rodando com DirectUnpack e DirectWrite ligados, que é como configuramos cada concorrente, e nestas formas isso basta para ocupar uma só cópia em disco. O SABnzbd guarda duas. A diferença que resta é aquela para a qual o pipeline foi construído: nunca materializamos os volumes, então o pico é a carga em si e não a carga mais o arquivo que a transportava.
Capacidade, não micro-benchmarks
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| NNTP com pipeline | sim | desligado por padrão | não | sim | - | - |
| verificação completa durante o download | cada bloco | depois | verificação rápida | depois | depois | depois |
| extração durante o download | no fluxo, sem volumes no disco | extração direta⁴ | extração direta⁴ | não confiável⁵ | não | não |
| disco necessário para uma publicação de N GB | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| veredito de completabilidade antes do download | exato por bloco | não | % de saúde | não | verificação de artigos | não |
| memória limitada (nunca faz swap) | orçada | 9.3 GB @ 190 GB | ajuste de cache | não | - | - |
| conferir o arquivo em qualquer ponto enquanto baixa | sim | não | não | não | sequencial | não |
| indexador integrado + mural de pôsteres | sim, sem chave | não | não | não | interface de busca | navegador de grupos |
| encaixe direto em Sonarr/Radarr | API SAB + Newznab | nativo | nativo | parcial | não | não |
| controles remotos de celular (nzb360/LunaSea) | via RPC do NZBGet | sim | sim | não | não | não |
| captura automática da lista de acompanhamento + melhorias | embutido | via *arr | via *arr | não | Watchdog | regras |
| binário único e autossuficiente | sim | Python | sim | sim | .app | .exe |
| código aberto | GPL⁶ | GPL | GPL | sim | pago | pago |
| plataformas | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | só mac | só win |
⁴ A extração direta ainda materializa os volumes primeiro: 2× escritas e 2× disco. ⁵ o rustnzb entregou volumes ofuscados marcados como "Concluído" na nossa rodada (sua extração também trava com o unrar da RARLab a menos que desativada). ⁶ GPL-3.0-or-later. Usenapp/Newsbin são leitores comerciais de plataforma única com recursos de baixador; estão listados porque as pessoas perguntam, não porque competem em velocidade.
Prova de transporte