Comment évaluer Immich avec une charge de travail reproductible sur un serveur domestique

Un benchmark Immich reproductible fixe le groupe de médias, le chemin client, l’état du cache, les tâches en arrière-plan simultanées et le point de terminaison mesuré avant de modifier une seule variable.

Sans ces contrôles, un deuxième essai plus rapide peut simplement refléter des données déjà en cache plutôt qu’un meilleur matériel, tandis qu’un test au repos peut masquer la concurrence liée à l’importation. Un benchmark utile pour un serveur domestique reproduit, dans le même ordre, les besoins réels du foyer en matière de navigation, d’envoi, de recherche et de récupération.

Définir les résultats attendus avant de recueillir les métriques

Commencez par définir des résultats observables, comme l’acceptation d’un envoi, le délai avant qu’une nouvelle photo soit consultable dans la recherche, l’achèvement des miniatures de la timeline, l’ouverture de l’original, le démarrage d’une vidéo ou le retour à une bibliothèque utilisable. L’utilisation du processeur et le débit du disque expliquent ces résultats, mais ne remplacent pas le résultat visible par l’utilisateur.

L’article de ZimaSpace consacré au chemin des données Immich distingue l’acceptation de l’envoi, la disponibilité du traitement, la sélection des résultats de recherche et la livraison des médias. Cette structure est utile, car un benchmark doit mesurer un seul point de terminaison plutôt que mélanger plusieurs étapes dépendantes en un total trompeur.

Sélectionnez deux points de terminaison interactifs et un point de terminaison en arrière-plan. Fixez pour chacun un objectif de réussite et consignez la médiane ainsi que la latence de la longue traîne ou le taux d’achèvement. Un benchmark comportant de nombreux scores sans lien devient difficile à interpréter ; un petit ensemble associé à une décision précise permet d’obtenir un résultat exploitable.

Figer le jeu de données, le chemin client et l’état initial

Utilisez les mêmes photos et vidéos représentatives à chaque essai, y compris des formats et des tailles correspondant à la bibliothèque familiale. Gardez constants le compte, l’appareil client, le chemin réseau, la version d’Immich et les paramètres des fichiers dérivés. Même une modification du cache du navigateur ou du chemin Wi-Fi peut éclipser la différence de configuration testée.

Un article consacré au benchmark de la recherche vectorielle insiste sur la reproductibilité des charges de génération d’embeddings, d’insertion et de récupération lors de l’étude des performances de recherche PostgreSQL. Immich est une application plus vaste, mais le principe expérimental s’applique également : des entrées contrôlées et des opérations de récupération définies sont indispensables avant que les différences de temps ne permettent de tirer une conclusion.

Créez un manifeste du jeu de données contenant les sommes de contrôle des fichiers, les nombres d’éléments, les totaux d’octets, les formats photo, les durées vidéo et les résultats de recherche attendus. Ajoutez une liste de vérification de départ couvrant le redémarrage des services, les actions de préchauffage, les tâches en file d’attente et les applications concurrentes. Si la liste de vérification diffère, marquez l’essai comme non comparable au lieu de l’inclure dans une moyenne.

Exécuter des phases à froid, à chaud et soutenues

La phase à froid révèle le coût de l’initialisation et du premier accès. La phase à chaud révèle la réutilisation lors de répétitions immédiates. La phase soutenue combine des interactions répétées avec un import représentatif ou une file d’attente en arrière-plan suffisamment longue pour faire apparaître la limitation thermique, la pression mémoire, les files d’attente du stockage et la concurrence entre ressources.

Un compte rendu de la communauté décrit une première recherche intelligente prenant environ cinq secondes, puis une répétition immédiate autour d’une demi-seconde lorsque la mémoire du modèle change. Ces chiffres ne constituent pas une norme de benchmark ; ils montrent pourquoi faire la moyenne des requêtes à froid et à chaud masque la transition que le test doit expliquer.

Exécutez chaque phase au moins trois fois, en conservant les horodatages bruts et les traces des ressources. Pour les tâches interactives, gardez la médiane et une mesure de la longue traîne ; pour les tâches en arrière-plan, consignez également le nombre d’éléments traités par minute. Arrêtez l’essai si des erreurs, une utilisation massive du swap ou des limites thermiques invalident la condition stable recherchée.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utiliser une fiche d’essai à variable unique

Formulez l’hypothèse avant l’essai : modifier l’emplacement de la base de données, la concurrence des workers, la limite de mémoire, le chemin réseau ou l’accélérateur devrait améliorer un point de terminaison nommé, par un mécanisme précis. Gardez tout le reste constant. Cela évite qu’une mise à niveau comportant plusieurs changements produise un résultat plus rapide sans cause défendable.

Une analyse générale des goulots d’étranglement explique que les limites du processeur, de la mémoire vive, du stockage et du réseau produisent des profils d’utilisation et des effets différents pour l’utilisateur. Appliquées à Immich, les métriques complémentaires doivent évoluer de manière cohérente avec le point de terminaison ; le graphique le plus chargé n’est pas automatiquement celui du composant limitant.

Consignez les résultats de référence et les résultats modifiés pour les phases à froid, à chaud et soutenues, puis indiquez réussite, échec ou résultat non concluant. Rejetez les améliorations qui disparaissent lors des répétitions ou qui provoquent des erreurs, des températures instables, une perte de progression dans la file d’attente ou une récupération plus longue. Conservez le manifeste et la fiche d’essai afin de pouvoir comparer honnêtement une future version.