Comment mesurer les performances d’Immich sans confondre cache et capacité

La capacité d’Immich doit être mesurée avec des charges de travail à froid, à chaud et soutenues, répétées, car une seule exécution rapide bénéficiant du cache peut masquer le véritable point de saturation du système.

Un serveur domestique peut rendre une chronologie ou un album extrêmement rapide après que les mêmes miniatures, pages de base de données et données d’application ont déjà été consultées. Ce résultat prouve que le chemin à chaud est efficace, mais pas que le système peut gérer durablement une bibliothèque familiale plus importante ou davantage d’activités simultanées. Un test de capacité utile doit contrôler l’état du cache, élargir l’ensemble de travail, répéter les exécutions et définir une condition d’arrêt mesurable.

La vitesse du cache n’est pas la capacité

La capacité décrit la quantité de travail représentatif qu’un système Immich peut soutenir avant que la latence, les files d’attente ou les erreurs ne deviennent inacceptables. La vitesse du cache répond à une question plus restreinte : à quelle vitesse le système peut-il répéter une opération lorsque les données utiles ou les ressources générées sont déjà à portée de main ? Si un test répète le même album ou la même chronologie, ces deux questions peuvent sembler identiques, alors qu’elles mesurent des conditions de fonctionnement différentes.

La différence est facile à observer dans les performances web, où les temps d’affichage à la première consultation et aux consultations suivantes peuvent diverger, car les requêtes ultérieures réutilisent les ressources mises en cache. Immich offre d’autres possibilités de fonctionnement à chaud, car les miniatures, les aperçus, les pages de base de données, les métadonnées du système de fichiers, le cache du système d’exploitation et les ressources du client peuvent tous être réutilisés. Une exécution répétée peut donc éliminer des opérations qu’une bibliothèque qui s’agrandit ou vient d’être consultée doit encore effectuer.

C’est pour la même raison qu’un test de Home Assistant axé sur le cache peut être trompeur lorsque les requêtes répétées dominent l’échantillon ; la discussion de ZimaSpace sur les couches de cache pour les requêtes répétées s’applique également à la logique de mesure présentée ici. Pour Immich, mesurez les performances à chaud, mais présentez-les comme un chemin distinct au lieu de les considérer comme la capacité générale du serveur.

Séparez les exécutions à froid, à chaud et en régime stable

Commencez par définir l’état du système avant de lancer le chronomètre. Une exécution à froid doit inclure des opérations qui n’ont pas été répétées récemment, comme l’ouverture d’une autre plage de dates ou d’un autre ensemble de ressources, après avoir laissé moins de possibilités aux caches d’aider. Une exécution à chaud répète volontairement un chemin connu. Une exécution en régime stable maintient une activité représentative suffisamment longtemps pour révéler le travail en arrière-plan, la réutilisation des ressources et les files d’attente qu’une courte rafale peut ne jamais faire apparaître.

La phase de chauffe elle-même peut être trompeuse. Percona décrit des cas où une base de données semble avoir terminé sa mise en cache alors que des processus en arrière-plan différés continuent de modifier les performances : le régime stable arrive donc plus tard que les premières requêtes rapides. Immich peut de même faire fonctionner en parallèle la navigation au premier plan, l’activité de la base de données, la génération de miniatures, l’indexation ou d’autres tâches en file d’attente, selon l’activité de la bibliothèque.

Pour un test de serveur domestique, exécutez chaque phase séparément au lieu de les combiner dans une moyenne. Indiquez si les tâches en arrière-plan sont inactives ou actives, gardez constants le client et le chemin réseau, puis répétez plusieurs fois la même phase. Si l’exécution à chaud est rapide, mais qu’une activité soutenue augmente progressivement la latence ou la profondeur de la file d’attente, le second résultat constitue le meilleur indicateur pour planifier la capacité.

Rendez l’ensemble de travail plus vaste que le cache facilement accessible

Un test qui ouvre les mêmes vingt photos est généralement trop limité pour répondre à une question de capacité concernant une bibliothèque familiale. Le système d’exploitation, la base de données, le client et la pile de stockage peuvent conserver un petit ensemble fréquemment utilisé à proximité du processeur, tandis que l’utilisation réelle alterne entre les mois, les personnes, les albums, les résultats de recherche et les vidéos. L’ensemble de test doit donc être suffisamment vaste et varié pour que toutes les opérations ne bénéficient pas des mêmes données récemment consultées.

Les pratiques d’évaluation des bases de données rendent cette distinction explicite : lorsqu’un test vise à examiner le stockage ou le comportement à froid, un cache résiduel peut transformer l’exercice en test de performance du cache. Vous n’avez pas besoin de purger chaque couche de cache d’un serveur Immich en production pour obtenir des informations utiles, mais vous devez utiliser une charge de travail dont l’ensemble de travail est plus large qu’un seul écran réutilisé en boucle.

Choisissez plusieurs plages de dates, albums, recherches et types de ressources qui correspondent à l’utilisation normale d’un foyer, puis alternez entre eux au lieu de solliciter une seule vue en continu. Conservez cette définition de la charge de travail pour les comparaisons entre matériels ou configurations. Si une modification n’améliore qu’un petit sous-ensemble répété, tandis que la navigation plus large continue de se dégrader sous charge, elle a amélioré le chemin à chaud sans repousser la limite de capacité utile.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mesurez les percentiles et répétez le test

Une seule moyenne peut masquer les moments que les utilisateurs remarquent réellement. Si neuf requêtes sont rapides et que la dixième reste bloquée pendant qu’une file d’attente se forme ou que le stockage est fortement sollicité, la moyenne peut tout de même sembler acceptable. Enregistrez au minimum le comportement médian et un percentile de queue tel que p95, puis associez la latence au débit, au nombre d’erreurs, au retard des tâches, à l’utilisation du processeur, à la pression mémoire et à l’activité du stockage afin de contextualiser le ralentissement.

L’analyse pratique des tests de performance recommande de communiquer p50, p95, p99 et la variance plutôt que de se fier à une seule exécution, en particulier pour les systèmes avec état où l’éviction du cache, la compaction ou l’activité en arrière-plan peuvent apparaître plus tard. Les tests Immich n’ont pas besoin d’une précision de laboratoire, mais ils doivent comporter suffisamment de répétitions pour distinguer une limite reproductible d’une période calme et chanceuse.

Exécutez le même scénario au moins plusieurs fois à chaque niveau de charge et conservez les observations brutes au lieu de ne garder que la meilleure exécution. Une affirmation de capacité devient plus crédible lorsque le p95 reste stable d’une exécution à l’autre et que le serveur résorbe les tâches en file d’attente entre les fenêtres de mesure. Si les résultats varient fortement, recherchez la variable non contrôlée avant d’affirmer que davantage d’utilisateurs, de photos ou un matériel plus rapide ont modifié le plafond.

Utilisez un protocole de capacité Immich avec une condition d’arrêt

Commencez avec une charge de travail représentative provenant d’un seul client et établissez une référence après que le système a atteint l’état que vous souhaitez tester. Augmentez ensuite une seule variable à la fois : davantage de navigations simultanées, d’importations, de recherches ou de traitements en arrière-plan, tout en gardant constants la bibliothèque, la combinaison de clients, le chemin réseau et la configuration du serveur. À chaque étape, enregistrez la latence p50 et p95, le nombre d’opérations réussies par minute, les erreurs, la croissance de la file d’attente et la principale ressource du serveur qui approche de la saturation.

Cette méthode évite l’erreur courante qui consiste à tirer des conclusions d’une seule courte exécution. Les recommandations en matière de tests de performance mettent en garde contre les conclusions fondées sur une seule exécution, car la chauffe, l’état du cache, le travail en arrière-plan et le bruit normal du système peuvent dominer un échantillon. Répétez chaque niveau de charge jusqu’à ce que la tendance soit suffisamment stable pour être expliquée, et pas seulement assez pratique pour être citée.

Définissez une règle d’arrêt avant de commencer le test. Une heuristique pratique pour un laboratoire domestique consiste à considérer la configuration actuelle comme saturée lorsque la latence p95 reste supérieure à environ deux fois la référence sans charge pendant trois fenêtres de mesure consécutives, ou lorsque les erreurs ou le retard des tâches continuent d’augmenter au lieu de se résorber ; il s’agit d’une heuristique de test, et non d’une limite d’Immich. La capacité utile correspond au dernier niveau de charge situé sous cette limite, mesuré avec le même protocole à froid, à chaud et en régime stable.