Combien d’utilisateurs simultanés Plex peut-il gérer avant de ralentir ?
Il n’existe pas de limite universelle utile pour le nombre d’utilisateurs Plex ; votre capacité de fonctionnement stable correspond au plus grand mélange réel de sessions qui passe avant que le stockage, le réseau ou le transcodage ne perdent leur marge.
Dix utilisateurs en lecture directe peuvent être moins exigeants que deux transcodages distants intensifs, et un serveur qui semble à l’aise pendant une lecture continue peut ralentir lorsque plusieurs spectateurs démarrent ou avancent dans la vidéo en même temps. Prenez en compte les modes de lecture réels, les débits, les chemins des sous-titres et du HDR, ainsi que l’utilisation du débit montant à distance. Ajoutez ensuite des sessions représentatives une par une et arrêtez-vous au premier goulot d’étranglement reproductible, au lieu d’estimer la capacité à partir du modèle de processeur ou du nombre de comptes.
Comptez les chemins de lecture, pas les comptes
Le nombre de personnes ayant accès à Plex n’est pas le nombre de charges de travail simultanées. Commencez par observer la période réelle la plus chargée et classez chaque session active comme lecture directe, flux direct, conversion audio uniquement ou transcodage vidéo. Ces modes consomment des ressources serveur très différentes.
Dix sessions simultanées ou plus peuvent tout de même produire des limites très différentes selon le nombre de chemins de lecture directe, de remuxage, de conversion audio et de transcodage vidéo actifs. Un simple nombre d’utilisateurs ne permet pas de prévoir le point de ralentissement.
Constituez un ensemble de tests à partir du chevauchement maximal crédible, et non de la liste complète des membres du foyer ou des amis. Si six utilisateurs se chevauchent rarement et utilisent tous la lecture directe, le problème de capacité est différent de celui posé par trois transcodages 4K simultanés.
Trouvez la première ressource partagée qui perd sa marge
Les sessions simultanées partagent le stockage des médias, l’interface réseau du serveur, les ressources processeur pour l’audio et les sous-titres, l’espace temporaire de transcodage et tout moteur vidéo matériel utilisé pour la conversion. La limite correspond à la première ressource requise qui arrive à saturation dans le mélange réel, et non au composant affichant le chiffre de spécification le plus élevé.
Les charges Plex à forte simultanéité peuvent révéler plusieurs goulots d’étranglement au niveau des disques, du réseau, du transcodage et des chemins de données internes. Appliquez la même approche multi-ressources à une échelle de serveur domestique plus réduite.
Consignez la latence du disque contenant les médias, le débit réseau, l’utilisation du processeur, les moteurs vidéo du GPU, la pression sur la mémoire et la vitesse de transcodage tout en ajoutant les sessions une par une. La première mesure qui perd régulièrement sa marge au même moment que la qualité de lecture constitue la limite de capacité utile.
Les utilisateurs distants ajoutent une limite distincte liée au débit montant
Les flux locaux peuvent rester entièrement à l’intérieur d’un réseau local rapide, tandis que chaque flux distant partage le débit montant de la connexion Internet domestique. Même un serveur puissant peut sembler lent du point de vue de l’utilisateur lorsque le débit combiné des flux originaux ou transcodés dépasse la capacité montante restante après les autres usages du foyer.
La capacité distante doit considérer la capacité réseau et celle du transcodage comme deux plafonds distincts. Un GPU plus rapide ne peut pas faire transmettre davantage de données à une liaison montante WAN déjà saturée.
Testez la simultanéité distante depuis l’extérieur du domicile, et non en ouvrant plusieurs onglets de navigateur locaux. Si le débit montant constitue le premier plafond, réduisez les débits distants ou améliorez la connexion avant d’acheter un processeur plus puissant. Si le débit montant reste confortable mais que la vitesse de transcodage diminue, le chemin de calcul constitue probablement la limite principale.
Les démarrages et les recherches révèlent la marge en rafale
La lecture en régime établi est souvent plus facile à gérer que plusieurs utilisateurs qui démarrent ou avancent dans leur vidéo au même moment. Ces moments provoquent des lectures en rafale, le remplissage de nouveaux tampons, des requêtes de métadonnées et de nouvelles connexions réseau avant la stabilisation de la charge.
Un nombre fixe de flux ne suffit pas pour planifier des transcodages simultanés ; le test d’acceptation doit inclure les formats de fichiers, les débits cibles, les chemins des sous-titres et le travail de conversion pouvant démarrer au même moment.
Mesurez le délai avant la première image et la reprise après une recherche pendant que le mélange de sessions cible est déjà actif. Si seuls les démarrages synchronisés échouent, la limite peut venir du stockage en rafale, de la latence liée à l’état des applications ou de la mise en file d’attente, plutôt que du calcul soutenu.
Les tâches en arrière-plan peuvent réduire la même marge
Les analyses, sauvegardes, téléchargements et tâches d’indexation peuvent consommer les mêmes capacités de stockage, de processeur, de mémoire ou de réseau que celles nécessaires aux spectateurs actifs. Un serveur qui réussit un test silencieux peut donc échouer lors du véritable pic d’utilisation du foyer.
Exécutez une fois le mélange de sessions cible avec la maintenance non essentielle suspendue, puis une fois avec une tâche représentative en arrière-plan active. La différence indique si la planification, plutôt qu’un matériel plus puissant, peut restaurer la marge.
Si la lecture échoue toujours lorsque les tâches en arrière-plan sont suspendues, maintenez la limite de simultanéité dans le chemin de lecture. Si l’échec disparaît, planifiez ou isolez la tâche concurrente et conservez la configuration serveur de référence, moins coûteuse.
Conservez dans le guide d’exploitation les définitions des charges de travail qui réussissent et qui échouent. La limite opérationnelle pourra ainsi être reproduite après une modification du client, du codec, du pool de stockage ou d’une tâche planifiée.
Définissez une limite opérationnelle à partir d’un test répété
Une limite de simultanéité utile est le mélange de sessions simultanées stable et reproductible, et non le nombre maximal qui fonctionne pendant trente secondes. Faites lire du contenu représentatif dans des scènes exigeantes, effectuez une recherche et observez le système suffisamment longtemps pour que les températures, les files d’attente et la vitesse de transcodage se stabilisent.
Un test de charge distante 4K ne permet de dimensionner le matériel qu’une fois la demande en lecture directe, le débit montant et le transcodage connus ; la limite de simultanéité reste ainsi liée à une charge mesurée plutôt qu’au nombre de comptes.
Documentez le mélange qui fonctionne et le premier mode d’échec. Si un flux supplémentaire en lecture directe sature le réseau, votre limite dépend du réseau. Si un transcodage supplémentaire passe sous le temps réel, elle dépend du calcul. Répétez le test après toute modification importante du client, du codec, du stockage ou du réseau, au lieu de considérer ce nombre comme définitif.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
