Mise en cache d’Immich : comment les données fréquemment consultées modifient les requêtes répétées

Les requêtes Immich répétées deviennent plus rapides lorsque les modèles, les pages de la base de données, les miniatures et les ressources du client restent suffisamment en mémoire pour éviter de refaire le travail de chargement initial.

La deuxième recherche ne prouve pas nécessairement que le serveur a gagné en capacité. Elle peut réutiliser des données préparées par la première requête ; des tests pertinents doivent donc déterminer quel état persiste et rendre compte séparément des comportements à froid et à chaud.

La première requête paie le coût de l’état manquant

Après un redémarrage ou une longue période d’inactivité, une requête Immich peut devoir charger en mémoire active des chemins de code, des poids de modèle, des pages de base de données et des fichiers de miniatures. Elle peut également déclencher l’établissement de connexions et la récupération des ressources du client. Les requêtes suivantes évitent une partie de ce travail, même si leur requête visible est identique.

Un rapport utilisateur mesure environ cinq secondes pour une première recherche intelligente et environ une demi-seconde pour une répétition immédiate, tandis que la mémoire GPU augmente au chargement du modèle. Ces chiffres dépendent de la configuration, mais la séquence observée montre pourquoi les premières recherches et les recherches répétées représentent des états système différents.

Notez précisément la condition à froid : redémarrage complet du conteneur, redémarrage du service d’apprentissage automatique, état client effacé ou intervalle d’inactivité défini. Ces conditions ne sont pas interchangeables. Un résultat simplement intitulé « à froid » ne permet pas de déterminer si le délai provenait de la présence du modèle en mémoire, du cache de pages du serveur, de l’établissement de la connexion ou de la réutilisation côté client.

La mise en cache existe à plusieurs niveaux indépendants

Il n’existe pas de paramètre de cache Immich unique expliquant chaque requête répétée. Le système d’exploitation peut conserver les pages de fichiers, PostgreSQL peut réutiliser les données fréquemment consultées, le processus d’apprentissage automatique peut conserver un modèle chargé, et les navigateurs ou applications mobiles peuvent réutiliser les miniatures et les ressources de l’application. Chaque couche a une durée de vie différente.

Un aperçu de la mise en cache à chaud explique la distinction générale : un cache chaud fournit les données conservées avec moins de délai, tandis qu’un cache froid doit les récupérer depuis une source primaire plus lente. Dans Immich, cette source primaire peut être le stockage persistant, et les « données » peuvent être des fichiers multimédias, des pages de base de données ou des fichiers de modèle.

Effectuez des réinitialisations sélectives. Répétez l’opération dans le même navigateur, puis avec un client vierge ; redémarrez uniquement le service d’apprentissage automatique, puis l’application ; enfin, redémarrez l’hôte. La première réinitialisation qui rétablit le délai important identifie la couche dont l’état conservé a le plus contribué à l’accélération, même si plusieurs couches peuvent se cumuler.

Les résultats à chaud peuvent masquer une limite de capacité

Un petit ensemble de recherches répétées peut maintenir exactement en mémoire les pages et miniatures nécessaires. Le test peut alors sembler excellent, tandis qu’une bibliothèque familiale plus vaste dépasse la mémoire disponible et provoque de fréquents défauts de cache. La capacité réelle apparaît lorsque l’ensemble de travail change, qu’un autre service évince les données ou qu’un redémarrage supprime l’état transitoire.

L’explication du chemin des données de ZimaSpace distingue la sélection dans la base de données de l’affichage des fichiers multimédias. Cela évite qu’une miniature chaude masque une requête lente, ou qu’une requête en cache masque une livraison de fichiers lente. Lors du diagnostic des gains liés aux requêtes répétées, mesurez séparément les identifiants de résultat et les ressources affichées.

Alternez entre plusieurs requêtes et différentes zones de la chronologie au lieu de répéter indéfiniment un seul élément. Incluez un intervalle d’inactivité représentatif et une charge concurrente. Un serveur dispose d’une capacité utile lorsque la latence acceptable persiste sur l’ensemble de travail attendu, et pas seulement lorsqu’un chemin très sollicité reste en mémoire.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rendez compte ensemble des exécutions à froid, à chaud et perturbées

Établissez un protocole en trois parties. Exécutez d’abord le point de terminaison après une condition à froid documentée. Répétez-le ensuite immédiatement sans modifier les entrées. Enfin, introduisez la perturbation attendue — période d’inactivité, autre conteneur ou ensemble de requêtes plus vaste — puis répétez l’opération. Relevez la latence médiane et la latence de la longue traîne plutôt qu’une seule valeur mesurée au chronomètre.

Un fil d’assistance consacré à la première recherche rapporte un délai initial de dix à quinze secondes, suivi de répétitions presque instantanées, ce qui renforce la nécessité de conserver les deux distributions. Cela n’établit pas une durée Immich universelle ; le choix du modèle, l’accélérateur, la mémoire, le stockage et la version peuvent tous modifier l’écart.

Concluez avec deux chiffres et une limite : la latence typique à chaud, la latence typique à froid et l’événement qui fait perdre l’état chaud. Si le comportement à froid ne respecte pas l’objectif du foyer, maintenez l’état nécessaire en mémoire ou améliorez ce chemin de chargement. Si seuls les tests artificiels à froid échouent, documentez la condition opérationnelle acceptée.