Les performances de Plex sont faciles à surestimer lorsqu’un test répété est servi depuis le cache au lieu de solliciter le stockage, le réseau ou le chemin de calcul que vous cherchez à mesurer.
Le cache est un comportement utile en production, et non une erreur à éliminer, mais il répond à une question différente de celle de la capacité. Un film déjà chargé, une affiche mise en cache ou une recherche répétée peuvent sembler considérablement plus rapides que le premier accès. La méthode consiste à étiqueter les exécutions à froid, à chaud et en régime stable, à contrôler le client et le mode de lecture, puis à surveiller les métriques des appareils sous-jacents avant de considérer le résultat le plus rapide comme une capacité durable.
Définir la capacité comme une performance que le système peut maintenir
La capacité correspond à la charge que l’ensemble du chemin Plex peut maintenir pendant la période pertinente : lectures simultanées, transcodages, activité des métadonnées et distribution réseau, sans prendre de retard. Le cache peut augmenter les performances à court terme en servant les données réutilisées depuis une couche plus rapide, mais cette pointe ne prouve pas que la ressource de stockage sous-jacente, plus lente, peut maintenir le même débit indéfiniment.
Lorsque l’ensemble de travail tient en mémoire, les résultats de benchmark avec cache à chaud peuvent différer fortement du comportement lors du premier accès. Pour Plex, indiquez si une exécution est à froid ou à chaud au lieu de traiter chaque résultat répété comme la même mesure de capacité.
Formulez l’affirmation de performance avant de tester. Si la question est « ce serveur peut-il maintenir trois flux distants pendant l’exécution d’une sauvegarde ? », la relecture à chaud, pendant dix secondes, d’un seul fichier ne constitue pas le test de capacité pertinent.
Effectuer les tests à froid et à chaud sur le même chemin multimédia
Une exécution orientée « à froid » commence dans un état où le fichier ou les métadonnées exacts ont moins de chances de résider dans le cache le plus rapide, tandis qu’une exécution à chaud répète peu après la même requête. Il est difficile de garantir un état parfaitement froid sur un serveur domestique en fonctionnement ; utilisez donc des étiquettes et les observations des appareils plutôt qu’une purge destructive du cache.
Si vous effectuez un réchauffement du cache entre les exécutions du benchmark, documentez délibérément cet état. Répétez le même fichier, le même client, la même qualité et le même schéma de recherche, puis notez la quantité d’activité du périphérique de stockage sous-jacent ou du réseau qui disparaît lors du passage suivant.
Si l’exécution à chaud s’améliore tandis que les lectures du périphérique de stockage sous-jacent diminuent fortement, le cache contribue au gain. Cela améliore réellement l’expérience utilisateur, mais le résultat à froid reste important pour les nouveaux titres, les grandes bibliothèques et les ensembles de travail qui dépassent la capacité du cache.
Surveiller le périphérique de stockage sous-jacent lorsque Plex semble rapide
La fluidité de la lecture ne permet pas à elle seule de déterminer si les données proviennent de la RAM, d’un cache SSD, d’un cache de métadonnées ou du disque multimédia d’origine. Associez les temps mesurés par l’utilisateur aux compteurs de latence du stockage, de débit de lecture, de processeur, de processeur graphique et de réseau afin de donner une explication physique au chemin rapide.
Augmenter la taille du cache n’améliore pas automatiquement toutes les charges Plex. Considérez la taille du cache comme une hypothèse à tester, et non comme un substitut à la mesure de la ressource lente de stockage, de réseau ou de calcul qui se trouve en dessous.
Pour la navigation dans les métadonnées, comparez les entrées-sorties de l’appareil correspondant à l’état de l’application avec les temps d’affichage des affiches et de la bibliothèque. Pour la distribution multimédia, comparez les lectures du périphérique source avec le trafic réseau sortant. Différents caches peuvent accélérer simultanément différentes parties de Plex.
Utiliser un ensemble de travail plus grand que le cache pour les tests prolongés
Un test de capacité doit finalement obliger le système à servir des données qui ne peuvent pas toutes rester dans le cache le plus rapide. Alternez entre plusieurs titres volumineux, différentes bibliothèques ou sessions simultanées suffisamment longtemps pour que le stockage sous-jacent et le réseau atteignent un régime stable, au lieu de relire un seul segment fréquemment utilisé.
Placer les métadonnées sur un stockage plus rapide peut améliorer la navigation et la réactivité de la bibliothèque tandis que les médias sources restent sur des disques plus lents. C’est pourquoi l’ensemble de travail et le rôle des données doivent être précisés avant de généraliser un résultat de benchmark.
Si les performances ne diminuent qu’après que le test dépasse la capacité du cache, le débit stable inférieur constitue le chiffre de capacité le plus fiable. Si elles restent stables et que les ressources sous-jacentes disposent encore d’une marge, le cache aide sans masquer un goulot d’étranglement.
Considérer les exécutions répétées et rapides comme un signal du cache, pas comme un échec
Le cache est précisément conçu pour accélérer les accès répétés ; l’objectif n’est donc pas de forcer chaque requête de production à passer par le disque. L’objectif est de savoir si le cache masque une ressource qui échouera lorsque la charge changera, augmentera ou deviendra simultanée.
La première exécution peut réchauffer le cache et modifier les mesures ultérieures, même si le périphérique sous-jacent n’est pas devenu plus rapide. Indiquez l’état du cache au lieu de prétendre qu’un serveur en fonctionnement n’en utilise aucun.
Lorsque la décision concerne précisément les lectures répétées depuis un NAS, comparez le cache de lecture SSD au disque direct. Une affirmation de capacité Plex n’est crédible que si le test décrit l’état du cache, l’ensemble de travail, la simultanéité et la ressource sous-jacente qui a réellement supporté la charge.
Centre Tech & IA
Plus à lire

Qu’est-ce que l’état de Plex et quelles parties doivent être persistantes ?
L’état persistant de Plex regroupe les informations qui préservent l’expérience du serveur après un redémarrage ou une reconstruction ; les données multimédias et les...

Comment Plex gère-t-il l’authentification entre les sessions locales et distantes ?
L’authentification Plex commence par l’identité du serveur et du compte, puis les chemins réseau locaux ou distants déterminent l’accessibilité et le fonctionnement de la...

Pourquoi la recherche dans Plex peut-elle ralentir à mesure que les données de la bibliothèque augmentent ?
La croissance de la bibliothèque n’est pas à elle seule la cause du problème. Testez la forme des requêtes, les index, l’état du cache,...

