Combien d’utilisateurs et de tâches en arrière-plan un seul hôte Jellyfin devrait-il prendre en charge ?

Ne dimensionnez pas un hôte Jellyfin en fonction du seul nombre d’utilisateurs enregistrés. Un foyer comptant huit comptes peut générer moins de charge que deux utilisateurs distants qui transcodent des vidéos 4K pendant qu’une analyse de bibliothèque, une tâche de sous-titres et une sauvegarde s’exécutent en arrière-plan. La question utile en matière de capacité est de savoir quelle quantité de tâches simultanées, au premier plan et en arrière-plan, l’hôte peut absorber avant que la lecture ou l’administration ne respecte plus ses objectifs.

Établissez un budget de charge unique qui inclut les sessions de lecture, les transcodages, les tâches planifiées, l’activité de stockage et les services hébergés en parallèle. Testez ensuite le chevauchement habituel le plus chargé et cessez d’augmenter la charge dès que la première ressource partagée présente une file d’attente persistante, des erreurs ou un délai perceptible par l’utilisateur.

Convertissez les utilisateurs en charges de lecture

Distinguez les sessions de lecture directe, de remultiplexage, de conversion audio et de transcodage vidéo. Les clients Jellyfin indiquent les codecs, résolutions, débits et contraintes qu’ils prennent en charge ; deux utilisateurs regardant la même source peuvent donc imposer des charges très différentes au serveur.

Les règles d’accès des utilisateurs Jellyfin peuvent également modifier la demande imposée au serveur. Les commandes actuelles de gestion des utilisateurs permettent d’autoriser ou de restreindre l’accès à distance, la lecture de médias, le transcodage et le débit Internet par flux. Le nombre d’utilisateurs n’est donc pertinent qu’une fois traduit en autorisations et modes de lecture prévus simultanément.

Commencez par le scénario habituel le plus exigeant d’une soirée, plutôt que par le nombre théorique maximal de comptes. Si, habituellement, le foyer utilise deux sessions locales en lecture directe et une conversion à distance, c’est la charge de référence que l’hôte doit pouvoir gérer sans difficulté.

Intégrez les tâches planifiées au même budget de capacité

Jellyfin effectue des tâches même lorsque personne n’appuie sur Lecture. Les analyses de bibliothèque, les téléchargements de sous-titres, le nettoyage du cache, les mises à jour de modules, l’extraction d’images de chapitres, l’optimisation de la base de données et les tâches de génération de médias peuvent se chevaucher avec le visionnage.

La liste actuelle des tâches planifiées montre que Jellyfin peut effectuer en arrière-plan des analyses, l’extraction d’images, des mises à jour de modules, la maintenance de la base de données, des tâches liées aux sous-titres, le nettoyage du cache et d’autres opérations. Des modules peuvent ajouter d’autres tâches.

Ne dimensionnez pas le serveur à partir d’un test de lecture silencieuse pour ensuite laisser toutes les tâches lourdes s’exécuter pendant le même pic. Commencez par reporter les tâches différables en dehors de la plage de visionnage ; incluez dans le test de production celles qui doivent se chevaucher.

Repérez la première ressource partagée qui manque de marge

Un hôte peut être limité par le débit du moteur multimédia, le CPU, la mémoire, la latence du SSD, la charge de recherche des disques durs, la bande passante réseau ou une dépendance. Ajouter des cœurs CPU n’aide pas si le lien de téléversement distant est saturé, et ajouter de la RAM ne résout pas un transcodage que le GPU choisi ne peut pas accélérer.

L’analyse de ZimaSpace sur la capacité de Jellyfin sur un petit serveur domestique suit le même modèle centré sur la charge de travail : la demande simultanée et la première ressource saturée comptent davantage qu’un plafond lié au nombre de comptes.

Mesurez la vitesse de transcodage, la saturation du CPU ou du moteur multimédia, la pression sur la mémoire, la latence du stockage et le débit réseau pendant le chevauchement exact des tâches. La ressource limitante est celle dont la pression augmente avec la défaillance et diminue lorsque cette pression est supprimée.

Featured

ZimaBoard 2 - Mini-serveur domestique pour vos grandes idées

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Évitez que les tâches d’arrière-plan consomment la marge disponible pour les tâches interactives

La lecture est soumise à une échéance : le segment suivant doit arriver avant que le tampon du client ne soit vide. Une analyse de bibliothèque peut généralement se terminer plus tard sans gêner personne. Cette différence doit guider la planification et la gestion des ressources.

Prévoyez une marge suffisante pour que le démarrage ou la recherche dans une lecture reste réactif pendant que les tâches d’arrière-plan inévitables se poursuivent. Si une optimisation de base de données ou une analyse des médias entraîne une mise en mémoire tampon, planifiez-la à un autre moment ou limitez-la avant d’acheter un serveur plus puissant.

Sur un hôte partagé, répétez le test avec les autres conteneurs actifs. Un téléchargeur, un indexeur de photos, un moteur de sauvegarde ou un processus d’IA local peut réduire la capacité de Jellyfin, même si sa propre charge de travail n’a pas changé.

Utilisez une matrice de charge de travail plutôt qu’une limite d’utilisateurs

Publiez la capacité sous la forme d’une charge de travail testée, par exemple « trois flux représentatifs et une analyse planifiée restent dans les limites visées », et non « ce serveur prend en charge dix utilisateurs ». Ce résultat peut être reproduit lorsque la bibliothèque, les clients et l’usage du foyer changent.