Cuatro clientes, siete escenarios, hardware y proveedores idénticos, ejecuciones intercaladas para que la deriva del proveedor se cancele. La métrica es el tiempo hasta un archivo usable: descargado, verificado, extraído. Incluye los tramos que no ganamos.
En esta página
Primero la metodología
pipelining_requests=8 (viene con 1, es decir, sin pipeline; ese ajuste por sí solo bajó su tiempo de 190 GB de 24m24s a 19m02s), NZBGet recibió ArticleCache/DirectWrite/DirectUnpack/ParQuick, y rustnzb su configuración documentada.Escenario 1 · limpio, enorme
| nzbfast | NZBGet 26.2 | SABnzbd 5.0.4 | rustnzb 1.3.4 | |
|---|---|---|---|---|
| tiempo hasta archivo usable | 4m 33s | 7m 58s (+75%) | 19m 32s (+329%) | ninguno¹ |
| GB por el cable | 169.6 | 169.8 | 169.7 | 186.5 |
| RSS pico | 1.4 GB² | 1.5 GB | 1.8 GB | 0.6 GB |
¹ rustnzb terminó de mover bytes a los 5m 42s tras haber traído 186.5 GB (un 10% más de cable que nadie) pero no dejó ningún medio extraído, su tercera ronda fallida consecutiva en esta publicación. · ² la memoria de nzbfast sigue su presupuesto configurado, no el trabajo: este tramo se ejecutó con el presupuesto automático por defecto y alcanzó un pico de 1.4 GB; un presupuesto deliberadamente enorme de 64 GB solo aporta un 4% (4m 22s), y limitado a 1 GB, el mismo trabajo de 190 GB también se completa (mira la escalera de baja memoria más abajo). En la ronda anterior de costa este (línea de ~2.4–3 Gbps) el mismo escenario corrió en 9m 00s frente a NZBGet +30% y SABnzbd +111%. La diferencia se mantiene a distintas velocidades de línea.
Escenario 2 · la diferencia crece con el tamaño
Una sola pasada significa que no hay pasada de verificación/desempaquetado posterior a la descarga, así que cuanto mayor es el trabajo, más ventaja saca. Ejecuciones secuenciales en la misma máquina:
| Trabajo | nzbfast | NZBGet | SABnzbd |
|---|---|---|---|
| 7.4 GB REMUX (Europa, 10 GbE) | 13.7 s | 17.3 s (+26%) | 19.0 s (+39%) |
| 35 GB 4K ofuscado (Europa) | 67 s | 108 s (+61%) | 285 s (+325%) |
| 87 GB 4K (costa este) | 272 s | 370 s (+36%) | 708 s (+160%) |
| 87 GB en un disco con 97 GB libres (Europa) | 3m 08s | no puede ejecutarse² | no puede ejecutarse² |
| 190.6 GB (costa este) | 9m 00s | 11m 43s (+30%) | 19m 02s (+111%) |
² Su huella máxima (volúmenes + salida desempaquetada a la vez, ~156 GB) superó los 97 GB libres. Una sola pasada necesita 1× el tamaño del contenido: reduce a la mitad el disco que necesitas, no solo el tiempo.
Escenario 3 · publicación ofuscada
| nzbfast | NZBGet | SABnzbd | rustnzb | |
|---|---|---|---|---|
| tiempo hasta archivo usable | 96 s | 153 s (+59%) | 259 s (+170%) | sin archivo usable³ |
| RSS pico | 1.55 GB | 3.7 GB | 8.8 GB | 3.6 GB |
³ rustnzb descargó en 119 s, marcó el trabajo como Completado, y entregó los volúmenes ofuscados en bruto: sin renombrado, sin extracción. nzbfast desofuscó a partir de los metadatos PAR2 y extrajo en el flujo, con cero bloques de relectura.
Escenario 4 · cola de tres
| nzbfast | rustnzb | NZBGet | SABnzbd | |
|---|---|---|---|---|
| tiempo total de la cola | 122 s | 136 s | 162 s | 277 s |
| línea ociosa (<20 MB/s) | 2 s (2%) | 16 s (12%) | 0 s | 168 s (61%) |
Tres formas del mismo problema: el solapamiento entre trabajos de nzbfast mantiene la línea ocupada de extremo a extremo; NZBGet nunca queda ocioso pero va ~35% más lento mientras desempaqueta en paralelo; SABnzbd descarga rápido y luego deja la línea a oscuras el 61% del tiempo durante el posprocesado en serie. En la variante de resiliencia (un trabajo con cabeceras RAR cifradas), la cola de SABnzbd se atascó en el trabajo cifrado y solo 1 de 3 trabajos llegó a completarse; nzbfast lo aparcó con un mensaje claro y terminó el resto.
La columna honesta
Las dos pruebas que estaban aquí se han vuelto a medir en la versión publicada y ninguna es ya una derrota: el post store-mode dañado nos lleva ahora 30 s frente a los 38 s de NZBGet, y la reconstrucción solo con paridad termina en 9 s donde antes tardaba 19 s, en una prueba en la que NZBGet responde en el mismo tiempo pero no entrega nada. Dejamos la sección aquí en lugar de borrarla: aquí es donde van nuestras derrotas, y la próxima ronda que encuentre una la devolverá.
Escenario 6 · privado de RAM
Los mismos cuatro trabajos, reejecutados con presupuestos de memoria fijos de 2 GB, 1 GB y 256 MB: lo que el autoajuste elegiría en un equipo de 8 GB, uno de 4 GB y un NAS de 2 GB. Cada tramo produjo un archivo correcto, totalmente verificado y extraído; el RSS pico siguió al presupuesto, no al trabajo. Tiempo hasta archivo usable, línea de 10 GbE:
| Tamaño del trabajo | RAM de sobra | presupuesto de 2 GB | presupuesto de 1 GB | presupuesto 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 |
El sobrecoste del 20–40% en los trabajos grandes es un artefacto de 10 GbE: los bloques desbordados solo cuestan tiempo cuando la línea supera al disco. El mismo trabajo de 87 GB con los mismos presupuestos en una línea de ~2.4 Gbps midió de −1% a +7%, ruido. En una conexión doméstica típica, un presupuesto pequeño es casi gratis a cualquier tamaño de trabajo. Un perfil NAS (2 conexiones, presupuesto de 256 MB) terminó el trabajo de 35 GB con 0.4 GB de RSS pico. Un NAS de 2 GB puede con esto. Ningún otro cliente ofrece siquiera un techo de memoria.
Escenario 7 · archivos dentro de archivos
Las publicaciones llegan cada vez más anidadas: un RAR dentro de un RAR, un 7z metido en un archivo en modo almacenamiento, una escalera de capas, una cadena de contraseñas. Esta ronda califica lo que le queda por hacer al operador. auto significa cada carga útil extraída, byte a byte idéntica, sin tocar nada; manual significa que el cliente informó de éxito pero dejó un archivo interno en el directorio de salida para que lo abras tú mismo.
| forma | nzbfast | SABnzbd | NZBGet | rustnzb |
|---|---|---|---|---|
| RAR en modo almacenamiento dentro de otro igual | auto | auto | manual | manual |
| RAR comprimido dentro de un RAR en modo almacenamiento | auto | auto | manual | manual |
| 7z dentro de un RAR en modo almacenamiento | auto | auto | manual | manual |
| escalera de 5 niveles, 6 cargas útiles | auto · 6/6 | manual · 3/6 | manual · 1/6 | manual · 1/6 |
| cadena de contraseñas, 3 niveles cifrados | auto · 3/3 | pide una contraseña | pide una contraseña | falló |
| completado automático, las diez formas | 8/10 | 6/10 | 2/10 | 2/10 |
Banco en bucle local, corpus generado por máquina, los cuatro clientes en la misma máquina, calificación por hash del contenido, así que un cliente que renombra la carga útil sigue recibiendo el mérito. Como las capas internas se desanidan al vuelo, nzbfast mantiene una sola copia de ~1.5 GB en disco donde los clientes de «escribir y desempaquetar» mantienen ~3 GB, y termina estos tramos en 1–2 s frente a 4–8 s. En la cadena de contraseñas, la contraseña de cada capa viaja en un archivo que extrae la capa de encima: nzbfast lo lee y desbloquea los tres niveles; los demás se detienen y esperan a que la escribas. Las dos formas que no completa en automático se califican con dureza a propósito: una escalera de 10 niveles más allá de su tope de profundidad por defecto y una publicación dañada en los tres niveles. En ambas recupera más cargas útiles que cualquier otro cliente, pero sale con código distinto de cero en lugar de llamar éxito a un trabajo parcial, así que ambas cuentan aquí como fallos.
Duelos de componentes
La extracción y el PAR2 son código nativo nuestro, así que también los hacemos competir en solitario contra el resto sobre corpus idénticos. Un tiempo solo cuenta cuando la salida es byte a byte idéntica a la carga útil de origen.
Frente a unrar 7.23, 7-Zip, bsdtar, unar y el crate rars original en un Apple M3 Ultra, el extractor de nzbfast gana o empata en todas las formas: 400 archivos pequeños en 0.13 s frente a los 0.66 s de unrar, solid 0.50 frente a 0.87, cifrado 0.49 frente a 0.82, un archivo RAR7 con diccionario de 128 MB 0.71 frente a 0.92. Repetido en un M1 Ultra de 20 núcleos y en un portátil Intel de 14 núcleos, el resultado se mantiene en todas las formas, y en el portátil los márgenes se amplían: las rutas de decodificación paralelas escalan con los hilos adicionales. Cada tiempo informado produjo una salida sha256 idéntica.
Frente al par2cmdline clásico, al fork SIMD par2cmdline-turbo y a MultiPar, nzbfast tiene la verificación más rápida y la reparación más rápida en todas las máquinas probadas. Escritorio de 20 núcleos: verificación limpia 0.40 s frente al 1.08 de turbo y el 3.67 del clásico; reparación de 101 bloques dañados 1.26 s frente a 2.61 y 7.52. Portátil de 14 núcleos: verificación 1.26 frente a 1.48, reparación 2.57 frente a 3.62. Cada archivo reparado byte a byte idéntico. Una nota honesta: no creamos PAR2 (un descargador no lo necesita, y ese tramo es de ParPar).
Lo que cuesta una tarea
La promesa de una sola pasada trata tanto del disco como de la velocidad, así que aquí está medida en lugar de afirmada: el máximo que alcanzó el directorio de trabajo durante las ejecuciones anidadas, muestreado dos veces por segundo. Leerlo una sola vez al final no diría nada, porque un cliente que borra sus volúmenes tras extraer parecería no haberlos escrito nunca.
| forma | nzbfast | NZBGet 26.2 | rustnzb 1.3.4 | SABnzbd 5.0.4 |
|---|---|---|---|---|
| RAR store dentro de RAR store | 1538 | 1538 | 1774 | 3080 |
| capa interna comprimida | 1536 | 1536 | 1674 | 3102 |
| RAR dentro de RAR, profundidad 2 | 1536 | 1536 | 1714 | 3076 |
| 7z envuelto en un RAR store | 1503 | 1536 | 1722 | 3102 |
Megabytes, menos es mejor. NZBGet nos iguala aquí y conviene decir por qué: se ejecuta con DirectUnpack y DirectWrite activados, que es como configuramos a cada competidor, y en estas formas eso basta para ocupar una sola copia en disco. SABnzbd guarda dos. La diferencia que queda es aquella para la que se construyó la tubería: nunca materializamos los volúmenes, así que el pico es la carga en sí y no la carga más el archivo que la transportaba.
Capacidad, no microbenchmarks
| nzbfast | SABnzbd 5 | NZBGet 26 | rustnzb | Usenapp | Newsbin | |
|---|---|---|---|---|---|---|
| NNTP en pipeline | sí | desactivado por defecto | no | sí | - | - |
| verificación completa durante la descarga | cada bloque | después | quick-check | después | después | después |
| extracción durante la descarga | en el flujo, sin volúmenes en disco | desempaquetado directo⁴ | desempaquetado directo⁴ | poco fiable⁵ | no | no |
| disco necesario para una publicación de N GB | ~1×N | ~2×N | ~2×N | ~2×N | ~2×N | ~2×N |
| veredicto de completabilidad previo a la descarga | exacto por bloque | no | % de salud | no | comprobación de artículos | no |
| memoria acotada (nunca swap) | con presupuesto | 9.3 GB @ 190 GB | ajuste de caché | no | - | - |
| comprobar el archivo en cualquier punto durante la descarga | sí | no | no | no | secuencial | no |
| indexador integrado + muro de pósteres | sí, sin claves | no | no | no | interfaz de búsqueda | explorador de grupos |
| Sonarr/Radarr listo para usar | API SAB + Newznab | nativo | nativo | parcial | no | no |
| mandos de teléfono (nzb360/LunaSea) | vía RPC de NZBGet | sí | sí | no | no | no |
| captura automática por lista de seguimiento + mejoras | integrado | vía *arr | vía *arr | no | Watchdog | reglas |
| binario único autocontenido | sí | Python | sí | sí | .app | .exe |
| código abierto | GPL⁶ | GPL | GPL | sí | de pago | de pago |
| plataformas | mac/win/linux/docker | mac/win/linux | mac/win/linux | linux/win | solo mac | solo win |
⁴ El desempaquetado directo sigue materializando primero los volúmenes: 2× escrituras y 2× disco. ⁵ rustnzb entregó volúmenes ofuscados marcados como «Completado» en nuestra ronda (su desempaquetado además se cuelga con el unrar de RARLab salvo que se desactive). ⁶ GPL-3.0-or-later. Usenapp/Newsbin son lectores comerciales de una sola plataforma con funciones de descarga; aparecen porque la gente pregunta, no porque compitan en velocidad.
Prueba de transporte