Test et benchmark de NZB Fast face à SABnzbd et NZBGet

Dernière mise à jour: 11/11/2026

NZB Fast est un nouveau téléchargeur Usenet qui promet d’extraire les archives pendant leur téléchargement, pour réduire l’attente et l’espace nécessaire. Nous avons testé cette idée sur un NAS domestique face à SABnzbd et NZBGet, deux clients très utilisés.

Ce que fait NZB Fast

Les utilisateurs d’Usenet connaissent le processus : un fichier NZB indique les articles à récupérer. Le client les télécharge, répare les dommages avec les fichiers PAR2, puis extrait les archives RAR, 7z ou zip pour obtenir les fichiers finaux.

SABnzbd et NZBGet permettent aussi une extraction anticipée avec Direct Unpack. Téléchargement et extraction peuvent se chevaucher, mais conserver les archives avec les fichiers finaux présente encore deux coûts possibles :

• Environ deux fois la taille de la publication en espace libre, puisque archives et fichiers extraits coexistent.
• Une réparation ou extraction restante peut retarder la fin du traitement au-delà du téléchargement.

NZB Fast extrait chaque volume dès son arrivée. Le projet parle de téléchargement en une passe. En théorie, la tâche se termine avec le téléchargement et demande environ 1x la taille de la publication en espace libre.

Il intègre aussi des fonctions confiées ailleurs à d’autres programmes : recherche dans les indexeurs, liste de suivi, navigateur multimédia et aperçu. Son API imite SABnzbd ou NZBGet pour que Sonarr et Radarr puissent l’utiliser comme client de téléchargement. Les serveurs d’une configuration SABnzbd existante peuvent être importés.

Notre méthode de test

Nous voulions un test reproductible avec un contenu clairement légal.

• La publication : Nous avons téléchargé l’ISO officielle Debian 13.7.0 DVD-1 (3,99 Go), vérifié son SHA-512, créé des volumes RAR de 100 Mo et ajouté des fichiers PAR2 avec 10 % de récupération. Nous l’avons ensuite publiée nous-mêmes dans alt.binaries.test. Les 6 162 articles étaient tous présents sur le serveur de téléchargement.
• Le matériel : Un NAS Ugreen avec quatre cœurs et 7,5 Go de RAM, sous Docker. Chaque client fonctionnait seul dans son propre conteneur, avec un dossier de téléchargement vide.
• Le serveur : Le même serveur Newshosting américain et 20 connexions pour chaque application. Nos autres conteneurs restaient actifs : le NAS n’était pas au repos.
• Les passages : Trois par configuration, avec rotation de l’ordre à chaque tour. Le chronomètre allait de l’envoi du NZB à la fin annoncée par l’application. Après chaque passage, nous comparions l’ISO extraite à la somme publiée par Debian.
• Les réglages : Les valeurs par défaut des applications, plus Direct Unpack activé pour SABnzbd et NZBGet, leur propre mécanisme d’extraction anticipée.

Les tests principaux ont eu lieu le 10 novembre 2026, heure du Pacifique, à partir du 11 novembre à 03:33 UTC. Ce sont nos mesures sur NAS, pas les benchmarks publiés par le développeur.

Versions testées : NZB Fast 1.10.0, SABnzbd 5.1.3 et NZBGet 26.3. Nous les avons retrouvées dans les conteneurs conservés : l’image immuable de NZB Fast porte la version 1.10.0 ; les anciens journaux de démarrage identifient celles de SABnzbd et NZBGet. Les trois conteneurs ont été créés avant les tests principaux. Les fichiers de résultats initiaux ne contenaient pas les versions : nous avons donc examiné les conteneurs plutôt que d’assimiler l’étiquette latest actuelle à la version testée. La version v1.10.0 de NZB Fast est datée du 10 novembre.

Résultats

Vitesse

Le graphique représente la médiane des trois passages par une barre et chaque passage par un point pour rendre la dispersion visible.

Les mêmes chiffres en tableau, avec le maximum d’espace disque : la plus grande occupation d’un passage, mesurée en blocs alloués.

Les 15 passages principaux ont réussi et produit une ISO conforme à SHA-512. Le « débit jusqu’aux fichiers terminés » est la taille utile divisée par le temps total de traitement, pas une mesure séparée du débit réseau.

Points marquants :

• NZB Fast était le plus rapide à chaque tour. Environ 16 % plus rapide que SABnzbd et presque deux fois plus rapide que NZBGet par défaut. Ses trois passages ont duré entre 100 et 111 secondes.
• L’affirmation sur l’espace disque s’est vérifiée. NZB Fast a culminé vers 3,7 Gio pour une publication de 3,7 Gio. Toutes les autres configurations approchaient 7,4 Gio.
• Direct Unpack n’apportait pas un gain automatique. Il a aidé NZBGet dans cette série, tandis que SABnzbd prenait plus de temps. Trois passages ne permettent pas d’affirmer qu’il ralentit généralement SABnzbd.
• Les temps variaient. SABnzbd avec Direct Unpack allait de 130 à 190 secondes. Interprétez prudemment les écarts de 10 à 20 % entre concurrents proches.

Espace disque

Le principe de NZB Fast apparaît ici. Pour cette charge, SABnzbd et NZBGet culminaient vers deux fois la taille de la publication, même avec Direct Unpack. Les chiffres portent sur l’espace alloué dans les dossiers de téléchargement, pas sur tout le stockage du système ou des conteneurs.

L’évolution dans le temps explique pourquoi. Les anciens clients montent progressivement vers 7,4 Gio, puis reviennent à 3,7 Gio après suppression des archives. NZB Fast réserve l’espace du fichier final dès les premières secondes et est resté proche de cette allocation pendant le test sans dommages.

Deux tests supplémentaires

Les premiers résultats concernaient une publication intacte avec 20 connexions. Nous avons aussi testé une publication endommagée et 40 connexions, avec deux passages par application dans chaque scénario supplémentaire. Ces séries étaient distinctes et la charge de fond variait : comparez les clients au sein d’un scénario, sans attribuer à lui seul un écart entre séries au bénéfice d’un réglage.

Une publication endommagée

Des articles Usenet peuvent manquer. Nous avons retiré 92 articles, soit 1,5 % des données RAR, du NZB. Chaque client devait donc réparer avec les PAR2 avant l’extraction. Nous avons lancé chaque application deux fois.

Chaque application a réparé l’ISO à l’identique, mais les durées différaient fortement. NZB Fast a pris 226 secondes, environ un quart de moins que SABnzbd à 305 secondes. NZBGet a pris 641 secondes, presque trois fois le temps de NZB Fast. Le pic disque de NZB Fast n’a augmenté que légèrement, à 4,0 Gio.

Davantage de connexions

Nos 20 connexions sont inférieures à la limite autorisée par Newshosting. L’outil de réglage de NZB Fast conseillait d’en augmenter le nombre ; nous avons donc retesté chaque client avec 40.

Il s’agit de médianes de deux passages par application. NZB Fast et NZBGet terminaient plus tôt dans la série à 40 connexions, contrairement à SABnzbd. Les séries ayant eu lieu à des moments différents sur un NAS occupé, cela ne prouve pas que le nombre de connexions explique seul ces écarts. Testez vos réglages au lieu de supposer que davantage de connexions est toujours préférable.

Faut-il l’utiliser ?

Pour une machine de téléchargement disposant de peu de stockage, peut-être. Le double espace nécessaire pose un vrai problème sur un petit SSD ou un NAS presque plein ; NZB Fast a évité cette allocation supplémentaire dans notre test sans dommages.

Si SABnzbd fonctionne déjà bien, le gain de vitesse sur un téléchargement intact reste modeste. Vingt secondes sur 4 Go ne changent pas le quotidien ; connexion et fournisseur comptent davantage. L’écart augmentait avec les données endommagées : NZB Fast terminait environ un quart plus vite que SABnzbd. C’est prometteur, mais notre publication volontairement endommagée ne représente pas tous les problèmes de réparation.

Points de vigilance

• Applications non signées. Les versions macOS et Windows ne sont ni notariées ni signées ; attendez-vous à des avertissements au premier lancement. Docker évite cela.
• Responsable inconnu. Nous n’avons pas identifié le responsable du projet. Cela compte pour un programme qui conserve les identifiants du fournisseur.
• Logiciel récent. SABnzbd et NZBGet sont maintenus depuis longtemps. NZB Fast est beaucoup plus récent, avec une communauté plus petite.
• Doublons. NZB Fast retenait une seconde copie de la même publication comme « alternative » jusqu’à ce que nous vidions la file. NZBGet ignorait aussi un NZB reconnu comme doublon. Cette protection est raisonnable, mais peut surprendre lors d’un téléchargement volontairement répété.
• Pas toujours une passe. Les archives auto-extractibles, zip fractionnés et tâches reprises reviennent à la méthode plus lente avec deux copies.

L’essayer

1. Lancez l’image Docker nzbfast/nzbfast. Le tableau de bord utilise le port 6789.
2. Ajoutez le serveur Usenet dans le tableau de bord ou importez les serveurs depuis SABnzbd. Respectez la limite de connexions du fournisseur.
3. Ajoutez un NZB ou connectez Sonarr et Radarr avec la clé API.
4. Rendez le tableau de bord accessible uniquement sur votre réseau domestique.

Notre conclusion

NZB Fast a tenu ses principales promesses dans notre test : le plus rapide, avec moitié moins de disque. Ses limites de sécurité et son responsable inconnu nous incitent à un essai local, sans nous y fier entièrement pour l’instant. D’autres publications, les empreintes d’image enregistrées à chaque passage et un NAS autrement au repos renforceraient un prochain test.

Pour les fonctions, la configuration et la sécurité, consultez le projet NZB Fast. Pour une solution éprouvée, lisez notre avis sur SABnzbd.