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

Un serveur Jellyfin ne doit pas être dimensionné 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 une vidéo 4K pendant qu’une analyse de bibliothèque, une tâche de sous-titrage et une sauvegarde s’exécutent en arrière-plan. La question utile concernant la capacité est de savoir quelle quantité de travail simultané, au premier plan comme en arrière-plan, le serveur peut absorber avant que la lecture ou l’administration ne respecte plus les objectifs fixés.

Établissez un budget de charge unique incluant les sessions de lecture, les transcodages, les tâches planifiées, l’activité du stockage et les services hébergés conjointement. Testez ensuite le chevauchement normal le plus chargé et cessez d’augmenter la charge dès qu’une première ressource partagée commence à présenter une mise en file persistante, des erreurs ou un délai perceptible par l’utilisateur.

Convertir les utilisateurs en charges de lecture

Comptez séparément les sessions en lecture directe, en remuxage, en conversion audio et en 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 demander au serveur des traitements très différents.

La politique utilisateur de Jellyfin peut également modifier la demande imposée au serveur. Les contrôles actuels de gestion des utilisateurs permettent d’autoriser ou de restreindre l’accès distant, la lecture des médias, le transcodage et le débit Internet par flux. Le nombre d’utilisateurs ne devient donc pertinent qu’une fois traduit en autorisations et en modes de lecture attendus simultanément.

Commencez par le scénario normal le plus exigeant d’une soirée, plutôt que par le nombre théorique maximal de comptes. Si le foyer utilise généralement deux sessions locales en lecture directe et une conversion distante, c’est cette base que le serveur doit supporter sans difficulté.

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

Jellyfin effectue des opérations même lorsque personne n’appuie sur Lecture. Les analyses de bibliothèque, téléchargements de sous-titres, nettoyages du cache, mises à jour des extensions, extractions d’images de chapitres, optimisations de base de données et 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 exécuter en arrière-plan des analyses, extractions d’images, mises à jour d’extensions, opérations de maintenance de la base de données, tâches de sous-titrage, nettoyages du cache et autres opérations. Les extensions peuvent ajouter d’autres tâches.

Ne dimensionnez pas le serveur à partir d’un test de lecture effectué au calme pour ensuite laisser toutes les tâches lourdes s’exécuter pendant le même pic d’activité. Décalez d’abord les tâches pouvant être reportées en dehors de la période de visionnage ; intégrez dans le test de production celles qui doivent impérativement se chevaucher.

Identifier la première ressource partagée qui perd sa marge

Un serveur peut être limité par le débit du moteur multimédia, le processeur, la mémoire, la latence du SSD, la pression liée aux recherches sur les disques durs, la bande passante réseau ou une dépendance. Ajouter des cœurs processeur ne sert à rien lorsque la liaison montante distante est saturée, et ajouter de la mémoire vive ne résout pas un transcodage que le GPU choisi ne peut pas accélérer.

L’analyse de ZimaSpace consacrée à la capacité de Jellyfin sur un petit serveur domestique utilise le même modèle centré sur la charge : la demande simultanée et la première ressource saturée comptent davantage qu’une limite fondée sur le nombre de comptes.

Mesurez la vitesse de transcodage, la saturation du processeur ou du moteur multimédia, la pression mémoire, la latence du stockage et le débit réseau pendant le chevauchement exact. La ressource limitante est celle dont la pression évolue avec la panne et dont la situation s’améliore lorsque cette pression est supprimée.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Empêcher les tâches en arrière-plan de consommer la marge interactive

La lecture est soumise à une échéance : le segment suivant doit parvenir au client avant que son tampon ne soit vide. Une analyse de bibliothèque peut généralement se terminer plus tard sans nuire à personne. Cette différence doit guider la planification et la politique d’allocation des ressources.

Conservez suffisamment de marge pour qu’un démarrage ou une recherche de lecture reste réactif pendant que les tâches inévitables en arrière-plan se poursuivent. Si une optimisation de base de données ou une tâche d’analyse des médias provoque des mises en mémoire tampon, modifiez sa planification ou limitez-la avant d’acheter un serveur plus puissant.

Sur un serveur 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 la charge propre de Jellyfin n’a pas changé.

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

Présentez la capacité sous la forme d’une charge testée, par exemple « trois flux représentatifs plus une analyse planifiée restent dans les limites fixées », plutôt que « ce serveur prend en charge dix utilisateurs ». Ce résultat peut être reproduit lorsque la bibliothèque, les clients et les habitudes du foyer évoluent.