Combien d’utilisateurs simultanés Immich peut-il gérer avant de ralentir ?

Il n’existe pas de nombre universel utile d’utilisateurs Immich simultanés que tout serveur domestique puisse gérer, car « un utilisateur » peut correspondre à une navigation inactive, une recherche par visage, un téléchargement important, la lecture d’une vidéo ou plusieurs tâches en arrière-plan simultanées.

La capacité doit être mesurée comme la charge domestique maximale reproductible qui respecte encore vos propres critères de temps de réponse et d’erreur. Établissez une référence au repos, rejouez des actions mixtes réalistes, augmentez progressivement la concurrence de manière contrôlée et surveillez la première ressource saturée. Vous obtiendrez ainsi une plage de capacité défendable pour votre matériel et votre bibliothèque, plutôt qu’une limite d’utilisateurs arbitraire.

Définissez ce qui « ralentit » avant de compter les utilisateurs

Choisissez un petit ensemble d’actions visibles par l’utilisateur qui comptent chez vous : ouvrir la chronologie, charger un album ancien, effectuer une recherche, lire une vidéo et téléverser un lot. Déterminez avant le test ce qui constitue un échec, par exemple une latence inacceptable, des dépassements de délai, des échecs de téléversement, des interruptions de lecture ou une file d’attente qui continue de croître après l’arrêt des utilisateurs.

Ne mélangez pas les tâches au premier plan et en arrière-plan sans les consigner. La génération de miniatures, le transcodage vidéo, le traitement des visages, Smart Search, l’analyse des bibliothèques, la maintenance de la base de données et les sauvegardes peuvent consommer les mêmes ressources CPU, mémoire, disque et réseau que les utilisateurs actifs. Un test à « quatre utilisateurs » pendant une importation importante représente une charge différente de celle de quatre personnes parcourant une bibliothèque stable.

Consignez pour chaque résultat le matériel, la version d’Immich, l’emplacement de la base de données, le type de stockage, la liaison réseau, la taille de la bibliothèque et les tâches actives en arrière-plan. Sans ce contexte, un nombre d’utilisateurs simultanés ne peut pas être comparé de manière pertinente après une mise à niveau ou avec un autre serveur domestique.

Mesurez une référence à un utilisateur avec les tâches en arrière-plan maîtrisées

Commencez lorsque le système est dans un état connu et mesurez un parcours utilisateur représentatif. Capturez le temps de réponse côté client ainsi que l’utilisation du CPU, la pression mémoire, la latence ou l’utilisation du disque, le débit réseau, l’activité de la base de données et les files d’attente des processus Immich que vous pouvez observer.

Une affirmation sur la capacité n’a de sens que lorsque la charge, la durée du test et les critères de réussite sont explicites. Utilisez le test de capacité fondé sur la charge pour enregistrer une référence à un utilisateur, puis mesurez l’évolution de la latence, du débit et des erreurs lorsque la concurrence augmente.

Si un seul utilisateur est déjà lent, arrêtez le test de concurrence. Corrigez d’abord le goulot d’étranglement observé avec un seul utilisateur ; l’ajout de sessions ne ferait qu’amplifier un problème existant de stockage, de base de données, de CPU, de réseau ou de configuration, sans vous renseigner réellement sur le comportement d’évolution du serveur.

Augmentez progressivement la concurrence de manière réaliste

Ajoutez progressivement des utilisateurs ou des sessions client scriptées tout en conservant une répartition d’actions similaire entre les étapes. Une séquence domestique utile pourrait doubler le nombre de sessions actives à partir d’une petite valeur de référence, mais les chiffres exacts importent moins que le fait de ne modifier que la concurrence et de conserver la même définition de la charge.

Définissez les limites de latence, d’erreur et de débit avant le test, et utilisez des parcours réalistes en plusieurs étapes plutôt que de marteler un seul point d’accès. Une charge de test réaliste pour Immich devrait mélanger les actions réellement effectuées par votre foyer, plutôt que de considérer des demandes de connexion répétées comme un indicateur de la capacité d’un serveur photo.

Maintenez chaque étape assez longtemps pour que les caches, les files d’attente, les connexions à la base de données et la demande de stockage se stabilisent. Consignez à la fois le pic et la capacité du système à récupérer lorsque la charge est supprimée. Un serveur qui semble acceptable lors d’un bref pic, mais qui laisse une file de tâches croissante, a déjà dépassé un niveau durable pour cette charge.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Identifiez la première ressource qui sature

Lorsque la latence augmente fortement, corrélez l’horodatage avec le comportement des ressources. Une saturation du CPU pendant les recherches ou l’apprentissage automatique indique une pression sur les capacités de calcul ; une latence disque élevée avec un CPU modérément utilisé pointe vers la base de données ou le stockage multimédia ; des liaisons réseau saturées indiquent des limites de transfert ou d’accès à distance ; une augmentation des attentes de la base de données ou de la pression sur les connexions pointe vers la couche de données.

Les tâches en arrière-plan peuvent modifier le résultat, car la génération de miniatures, le transcodage, l’apprentissage automatique, les analyses, les sauvegardes ou les boucles de nouvelle tentative peuvent consommer des ressources même lorsque personne ne navigue activement. Comparez le test dans des conditions de charge en arrière-plan d’Immich maîtrisées, afin de ne pas confondre une tâche planifiée avec une faible limite d’utilisateurs.

Ne « corrigez » pas la capacité en masquant les erreurs avec des délais d’attente client plus longs. Modifiez la ressource limitante ou la politique de charge — par exemple en planifiant les tâches lourdes, en améliorant le placement du stockage, en réduisant le nombre de transcodages simultanés ou en ajoutant des capacités de calcul — puis rejouez exactement l’étape en échec pour vérifier que le goulot d’étranglement s’est déplacé ou a disparu.

Définissez une plage de capacité domestique pratique et retestez-la

Définissez la capacité pratique comme la concurrence maximale testée pour laquelle tous les parcours utilisateur requis restent dans vos limites de latence et d’erreur préalablement définies, les files d’attente reviennent vers leur niveau de référence après le test et l’hôte conserve une marge suffisante pour les tâches ordinaires en arrière-plan. Présentez-la comme une plage propre à la charge, et non comme un maximum valable pour tout Immich.

Répétez au moins une fois l’étape limite depuis un état propre et comparable, en incluant les actions qui avaient précédemment provoqué une dégradation. Testez ensuite brièvement l’étape supérieure afin de confirmer que la limite apparaît toujours au niveau de la même ressource, sans pousser le système vers une file d’attente incontrôlée ou un incident de pression sur le stockage.

Rejouez le même test après les mises à niveau majeures d’Immich, les changements d’emplacement de la base de données, les modifications du stockage ou du matériel, ou une forte augmentation de la taille de la bibliothèque. Votre capacité est une propriété du système et de la charge actuels ; conserver la procédure de test est plus utile que conserver un ancien nombre d’utilisateurs.