Combien de tâches simultanées Immich peut-il gérer avant que la réactivité de la recherche ne se dégrade ?

Immich n’a pas de nombre de tâches universellement sûr ; la recherche se dégrade lorsque les workers concurrents saturent la ressource dont les requêtes interactives ont également besoin.

Deux serveurs peuvent exécuter le même nombre de tâches de génération de miniatures, de métadonnées et d’apprentissage automatique, tout en produisant des latences de recherche très différentes. La limite utile est donc la charge mixte maximale qui maintient un objectif défini de temps de réponse interactif tout en permettant à la file de continuer à se vider.

Un nombre de tâches ne décrit pas la charge de travail

Une valeur de concurrence indique seulement le nombre de workers autorisés, et non une mesure directe de la pression exercée. La génération de miniatures, le transcodage vidéo, l’extraction de métadonnées et l’inférence d’apprentissage automatique mobilisent des quantités différentes de ressources de calcul et de stockage. Quatre tâches légères de métadonnées peuvent laisser l’interface réactive, tandis que deux tâches vidéo sollicitent beaucoup plus fortement le même hôte.

Un témoignage de la communauté concernant une forte utilisation du processeur par l’apprentissage automatique décrit la réduction du nombre de tâches concurrentes après une importation importante, ce qui a réduit la charge tout en allongeant le temps d’achèvement. Cette observation confirme le compromis central : une concurrence plus faible protège la réactivité au premier plan en permettant au retard de se résorber plus lentement, et non en supprimant le travail sous-jacent.

Traitez chaque file comme une catégorie de charge de travail. Notez quelles tâches sont actives, quels types de médias elles traitent et si une accélération est disponible. Une limite sûre établie à partir de petits fichiers JPEG ne peut pas être transposée aux photos RAW ou aux longues vidéos, car le travail représenté par chaque emplacement a changé.

La recherche se dégrade au premier point de saturation partagé

La recherche interactive traverse plusieurs couches partagées : la requête atteint l’application, la base de données sélectionne les résultats, les miniatures sont lues et un client les affiche. Les workers en arrière-plan peuvent se disputer les ressources à plusieurs niveaux. La première couche saturée devient le plafond pratique de concurrence, même lorsque chaque conteneur reste sain.

Une discussion sur les performances d’Immich décrit un chargement retardé des miniatures sur un hôte disposant d’une bande passante nominale suffisante, illustrant pourquoi la vitesse de la liaison ne suffit pas à identifier le goulot d’étranglement. La planification du processeur, les lectures de la base de données, la latence du système de fichiers et la distribution vers le client restent des hypothèses tant que les mesures n’indiquent pas quelle attente augmente pendant la requête lente.

L’utilisation doit être associée au délai. Un processeur fortement sollicité avec une latence de recherche stable peut correspondre à une saturation productive, tandis qu’une utilisation modérée du processeur accompagnée d’une hausse du temps d’attente disque peut révéler une file d’attente de stockage. La pression mémoire est importante lorsque la récupération de mémoire ou le swap ajoutent du délai, et pas simplement parce que le système d’exploitation utilise la RAM disponible comme cache.

L’indexation pour la recherche peut prendre du retard sans ralentissement des requêtes

Une requête rapide peut renvoyer une collection consultable incomplète lorsque les nouveaux éléments n’ont pas terminé leur indexation. À l’inverse, tous les éléments peuvent déjà être indexés tandis que les requêtes sont lentes en raison de la contention de la base de données ou du stockage. Appeler ces deux situations une « dégradation de la recherche » masque deux résultats différents et conduit à un mauvais ajustement de la concurrence.

L’explication de ZimaSpace concernant le chemin de données d’Immich distingue l’acceptation des importations, la disponibilité des aperçus et la récupération sémantique comme des résultats distincts. Cette distinction est essentielle lors des tests de charge : l’horodatage d’arrivée d’un fichier ne peut pas remplacer celui où sa représentation devient éligible à la recherche.

Suivez deux chronomètres pour une cohorte d’importation fixe. Le premier mesure la latence des requêtes interactives sur des photos de contrôle déjà indexées ; le second mesure le temps nécessaire pour que les photos nouvellement importées apparaissent dans des recherches prédéfinies. Le premier protège l’expérience utilisateur active, tandis que le second montre le coût en débit de la réduction de la concurrence.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Trouvez la limite avec un test par paliers, pas au hasard

Créez un lot de médias représentatif et choisissez trois recherches fixes qui renvoient des éléments connus. Commencez avec un worker dans chaque file active, exécutez l’importation et enregistrez, sur la même période d’observation, la latence médiane et celle de la longue traîne, le débit de vidage des files, le processeur, la pression mémoire, le débit réseau et le temps d’attente du stockage.

Les recommandations générales sur les goulots d’étranglement préconisent de corréler les changements de charge avec les attentes liées au processeur, à la mémoire, au disque, au réseau et aux dépendances, plutôt que de sélectionner le graphique qui semble le plus chargé. N’augmentez qu’un seul paramètre de concurrence par essai. Répéter la même séquence de recherches et utiliser la même cohorte de médias permet d’identifier clairement la variable modifiée.

Arrêtez-vous au premier palier où la cible de latence de la longue traîne pour la recherche échoue, où le serveur commence à utiliser le swap, où le temps d’attente du stockage reste élevé, où des erreurs apparaissent ou où la file d’arrière-plan cesse de gagner en débit utile. Retestez le palier précédent après un redémarrage à froid, puis de nouveau à chaud. Ce palier inférieur et reproductible constitue le plafond défendable pour cette charge de travail.