Pourquoi les lectures aléatoires révèlent-elles une latence cachée par les tests NAS séquentiels ?

Les lectures aléatoires exposent la latence du NAS domestique car elles remplacent un flux de données prévisible par de nombreuses requêtes séparées vers des emplacements non liés. Un test séquentiel peut montrer une excellente bande passante alors que la navigation quotidienne reste lente si chaque petite lecture, recherche de métadonnées ou absence de cache prend un temps notable à s’exécuter.

Les deux tests répondent à des questions différentes. Le débit séquentiel demande à quelle vitesse le chemin peut déplacer un flux continu ; le test de lecture aléatoire demande à quelle rapidité le NAS peut localiser et retourner de nombreux morceaux de données dispersés. Les applications, bibliothèques photo, arbres de sources et dossiers de petits fichiers dépendent souvent davantage du second comportement.

Que mesure réellement un test NAS séquentiel ?

Une grande lecture séquentielle progresse à travers des décalages adjacents dans un fichier ou une plage de blocs. La pile de stockage peut reconnaître la localité, fusionner les requêtes proches, lire en avance et transférer de grandes charges utiles avec moins de surcharge de commande par octet. La bande passante réseau et disque domine donc le résultat une fois le flux établi. Le délai de démarrage devient une petite fraction d’un long transfert, favorisant encore la moyenne rapportée.

La distinction est explicite dans les définitions de charge fio, qui séparent les lectures séquentielles des lectures aléatoires. Modifier uniquement ce schéma d’accès peut produire un résultat très différent même lorsque le matériel NAS domestique, le réseau et le volume total de données restent inchangés.

Cela ne rend pas les tests séquentiels trompeurs. Ils représentent fidèlement des tâches telles que le streaming d’un gros fichier média ou la copie d’une grande archive. Le problème commence lorsque ce résultat est traité comme une mesure universelle de la réactivité de navigation, du lancement d’applications ou de dossiers contenant des milliers d’objets non liés. Le nom du test devrait donc indiquer le type d’accès au lieu de présenter un seul chiffre de bande passante comme « vitesse NAS ».

Que change la perte de localité dans les lectures ?

Sans localité, la requête suivante peut cibler un bloc éloigné du précédent. Sur un disque dur, l'actionneur doit repositionner la tête et attendre que le secteur désiré tourne en place. La documentation Linux sur la couche bloc identifie la forte pénalité d'accès aléatoire des disques magnétiques et explique comment les requêtes adjacentes peuvent être fusionnées pour plus d'efficacité.

Un SSD évite la recherche mécanique, mais une charge de travail aléatoire crée toujours plus de commandes pour le même nombre d’octets lorsque la taille des blocs est petite. La recherche du contrôleur, la traduction flash, le travail du système de fichiers et la gestion du protocole doivent être effectués pour de nombreuses opérations individuelles, donc la latence et les IOPS comptent plus que la bande passante séquentielle maximale.

Au niveau du fichier, l’accès dispersé peut également inclure l’énumération des répertoires, la lecture des inodes ou des enregistrements de fichiers, les vérifications d’autorisations, les attributs étendus et les opérations d’ouverture/fermeture. Ces étapes peuvent être sérialisées par l’application ou le protocole, laissant peu d’opportunités à un lien à haute bande passante de compenser chaque cycle de latence de requête.

Pourquoi une moyenne rapide peut-elle masquer de nombreuses requêtes lentes ?

Le débit est la quantité totale de données divisée par le temps. Il peut rester élevé lorsque les grandes requêtes dominent le nombre d’octets, même si les petites requêtes s’exécutent lentement. Un utilisateur remarque le délai avant que le dossier suivant, l’aperçu ou l’élément de l’application n’apparaisse, pas le nombre moyen de mégaoctets déplacés sur l’ensemble du travail.

Ce tableau sépare les motifs synthétiques selon la question à laquelle chacun peut répondre. Les cas mis en cache et non mis en cache sont particulièrement importants car une deuxième exécution peut mesurer l’efficacité de la mémoire plutôt que celle des disques qui ont servi la première exécution.

Ce n’est pas une prédiction de la vitesse pour un NAS particulier. La taille des blocs, la profondeur de la file d’attente, la taille de l’ensemble de travail, la concurrence des clients, le protocole, le système de fichiers et la disposition des disques modifient tous le résultat. Un test utile contrôle ces paramètres et rapporte à la fois les octets par seconde et les percentiles de temps d’achèvement.

Comment le cache et la lecture anticipée favorisent-ils les tests séquentiels ?

La lecture anticipée prédit que les données suivant la plage actuelle seront bientôt nécessaires et les récupère avant que l'application ne les demande. Cela est efficace pour un flux en avant et beaucoup moins utile lorsque chaque décalage suivant est sans rapport. Linux expose une limite de lecture anticipée du périphérique de bloc, confirmant que le système de fichiers peut demander des données supplémentaires au-delà de la lecture immédiate.

La RAM peut encore accentuer cet écart. Les entrées de répertoire fréquemment consultées, les métadonnées des fichiers et les pages de données peuvent être renvoyées sans toucher au disque. Un test dont l'ensemble de données tient dans la mémoire disponible peut donc rapporter la vitesse du cache et du réseau, tandis qu'un ensemble de données plus grand ou froid expose la latence du stockage sous-jacent.

Le cache fait partie des performances réelles d'un NAS, il ne doit donc pas être désactivé automatiquement. Au lieu de cela, étiquetez séparément les résultats de cache chaud et de cache froid. Cette distinction montre si l'expérience utilisateur est rapide parce que l'ensemble de travail actif est conservé en mémoire ou parce que le stockage lui-même gère rapidement les manques.

Pourquoi les petits fichiers semblent-ils plus lents que ce que leur taille en octets suggère ?

Chaque fichier introduit un travail fixe qui ne diminue pas avec la charge utile. Le client localise une entrée de répertoire, vérifie les métadonnées, ouvre l'objet, lit son contenu et le ferme. Lorsque les fichiers sont minuscules, ces opérations représentent une part beaucoup plus importante du temps total que lors d'une lecture continue de plusieurs gigaoctets.

Les protocoles réseau peuvent ajouter des limites de requête et de réponse autour de ce travail. Même sur un LAN à faible latence, des milliers d'opérations partiellement sérialisées s'accumulent. Le délai résultant n'est pas simplement un « réseau lent » ou un « disque lent » ; c'est la latence combinée du client, du protocole, du système de fichiers, du cache et du périphérique. L'analyse antivirus, l'extraction d'aperçus et les vérifications au niveau de l'application peuvent prolonger le même chemin par fichier.

C'est pourquoi un ensemble de données d'application et un dossier de données média de taille égale peuvent se comporter différemment. Le choix pratique entre SMB et NFS peut modifier la mise en cache et le comportement des requêtes, mais ne transforme pas une charge de travail riche en métadonnées en un flux séquentiel.

Comment un NAS domestique devrait-il tester la latence réelle de navigation ?

Commencez par définir la charge de travail : taille des objets, mix lecture/écriture, nombre de fichiers, taille de l'ensemble de travail, nombre de clients, et si les données doivent être mises en cache. Exécutez une base de référence séquentielle importante, mais ajoutez des lectures aléatoires de taille fixe et un test au niveau des fichiers qui ouvre les mêmes types d'objets utilisés par l'application réelle. Maintenez la position des données et les conditions d'espace libre stables afin que les comparaisons ne mélangent pas les changements de schéma d'accès avec un état de stockage différent.

Rapportez ensemble les percentiles d'IOPS, de débit et de latence. Linux expose les opérations terminées, le temps passé sur les lectures et écritures, les fusions et les E/S en cours via les statistiques du noyau sur les disques. Ces compteurs aident à distinguer un périphérique occupé et un arriéré croissant d'un test limité par le client ou le réseau.

Répétez le test avec un seul client et avec une concurrence réaliste, tout en surveillant l’utilisation du CPU, de la mémoire, du réseau et l’activité disque. Si la vitesse des gros fichiers est élevée mais que la latence des petites lectures non mises en cache est mauvaise, la charge de travail des applications NAS peut être étudiée comme un chemin opérationnel supplémentaire plutôt que pour redéfinir le résultat de stockage.

FAQ

Les tests de lecture aléatoire sont-ils plus précis que les tests séquentiels ?

Ils sont plus représentatifs uniquement pour les charges de travail avec accès dispersé. Les tests séquentiels restent la bonne mesure pour le streaming et la copie de gros fichiers ; une évaluation complète du NAS utilise les deux au lieu de déclarer l’un universellement précis.

Pourquoi un second benchmark est-il souvent plus rapide ?

Le système d’exploitation ou le NAS peut servir des données et métadonnées précédemment lues depuis la RAM. Ce résultat de cache chaud est utile, mais il doit être indiqué séparément car il ne mesure peut-être plus le même chemin de stockage que la première exécution.

Le stockage SSD peut-il éliminer la latence des petits fichiers ?

Il peut grandement réduire la latence d’accès aux appareils, surtout comparé à un HDD lors de lectures aléatoires, mais il ne peut pas éliminer les allers-retours du protocole, le travail des métadonnées du système de fichiers, la sérialisation des applications ou la contention CPU.

Le 10GbE garantit-il une navigation NAS plus rapide ?

Non. Un lien plus rapide améliore le plafond de bande passante et peut réduire le temps de transfert pour les gros fichiers, mais la navigation peut rester limitée par la latence des petites requêtes. Le diagnostic plus large du NAS 10GbE est utile lorsque le test montre que le réseau n’est pas le seul goulot d’étranglement.

Quel chiffre de latence correspond le mieux à une interface lente ?

Utilisez la latence en percentile, en particulier le 95e ou 99e percentile, en plus de la médiane. Une médiane réactive peut coexister avec des requêtes occasionnellement longues qui retardent visiblement les vignettes, la navigation dans les dossiers ou les écrans d’application.

Conclusion finale

Les tests NAS séquentiels mesurent l'efficacité avec laquelle le chemin diffuse les données adjacentes ; les tests aléatoires et de petits fichiers révèlent combien de temps les requêtes dispersées attendent réellement. Lorsque la bande passante annoncée semble élevée mais que la navigation paraît lente, comparez les percentiles de latence en cache froid et les opérations de fichiers de bout en bout avant de blâmer uniquement la vitesse du réseau.