Immich-Caching: Wie häufig angeforderte Daten wiederholte Anfragen verändern

Wiederholte Immich-Anfragen werden schneller, wenn Modelle, Datenbankseiten, Miniaturansichten und Client-Assets warm genug bleiben, sodass zuvor erforderliche Ladevorgänge entfallen.

Die zweite Suche ist nicht zwangsläufig ein Beweis dafür, dass der Server Kapazität gewonnen hat. Sie kann auf Daten zurückgreifen, die von der ersten Anfrage vorbereitet wurden. Aussagekräftige Tests müssen daher ermitteln, welcher Zustand erhalten bleibt, und kaltes und warmes Verhalten getrennt ausweisen.

Die erste Anfrage bezahlt für fehlende Zustände

Nach einem Neustart oder einer längeren Leerlaufphase muss eine Immich-Anfrage möglicherweise Codepfade, Modellgewichte, Datenbankseiten und Miniaturansichtsdateien in den aktiven Speicher laden. Außerdem können Verbindungsaufbau und das Abrufen von Client-Assets ausgelöst werden. Spätere Anfragen überspringen einen Teil dieser Arbeit, obwohl ihre sichtbare Abfrage identisch ist.

Ein Nutzerbericht misst bei einer ersten intelligenten Suche ungefähr fünf Sekunden und bei einer unmittelbar folgenden Wiederholung etwa eine halbe Sekunde, während der GPU-Speicher beim Laden des Modells zunimmt. Die Werte sind konfigurationsabhängig, doch die beobachtete Abfolge zeigt, warum erste und wiederholte Suchen unterschiedliche Systemzustände darstellen.

Dokumentieren Sie die genaue Kaltstartbedingung: vollständiger Container-Neustart, Neustart des Machine-Learning-Dienstes, gelöschter Client-Zustand oder ein festgelegtes Leerlaufintervall. Diese Bedingungen sind nicht austauschbar. Ein Ergebnis, das lediglich als „kalt“ bezeichnet wird, kann nicht erkennen lassen, ob die Verzögerung durch die Modellresidentz, den Seiten-Cache des Servers, den Verbindungsaufbau oder die Wiederverwendung auf der Clientseite verursacht wurde.

Wärmezustände bestehen auf mehreren unabhängigen Ebenen

Es gibt keinen einzelnen Immich-Cache-Schalter, der jede wiederholte Anfrage erklärt. Das Betriebssystem kann Dateiseiten behalten, PostgreSQL kann auf häufig verwendete Daten zurückgreifen, der Machine-Learning-Prozess kann ein geladenes Modell behalten, und Browser oder mobile Apps können Miniaturansichten und Anwendungs-Assets wiederverwenden. Jede Ebene hat eine andere Lebensdauer.

Eine Übersicht zum Cache-Warming erklärt den allgemeinen Unterschied: Ein warmer Cache liefert gespeicherte Daten mit geringerer Verzögerung, während ein kalter Cache sie aus einer langsameren primären Quelle abrufen muss. Bei Immich kann diese primäre Quelle der dauerhafte Speicher sein, und bei den „Daten“ kann es sich um Medien, Datenbankseiten oder Modelldateien handeln.

Verwenden Sie selektive Zurücksetzungen. Wiederholen Sie den Vorgang zunächst im selben Browser und anschließend mit einem neuen Client; starten Sie dann nur den Machine-Learning-Dienst und danach die Anwendung neu; zuletzt starten Sie den Host neu. Die erste Zurücksetzung, die die lange Verzögerung wiederherstellt, identifiziert die Ebene, deren erhaltener Zustand am meisten beigetragen hat, auch wenn mehrere Ebenen zusammenwirken können.

Warme Ergebnisse können eine Kapazitätsgrenze verbergen

Eine kleine Gruppe wiederholter Suchen kann genau die benötigten Seiten und Miniaturansichten im Speicher halten. Dieser Benchmark kann hervorragend aussehen, während eine größere Familienbibliothek den Speicher übersteigt und häufige Fehlzugriffe verursacht. Die Kapazität zeigt sich, wenn sich die Arbeitsmenge ändert, ein anderer Dienst Daten verdrängt oder ein Neustart den flüchtigen Zustand entfernt.

Die Erklärung des Immich-Datenpfads von ZimaSpace trennt die Datenbankauswahl von der Medienanzeige. Dadurch wird verhindert, dass eine warme Miniaturansicht eine langsame Abfrage oder eine zwischengespeicherte Abfrage eine langsame Dateiauslieferung verdeckt. Messen Sie bei der Diagnose von Verbesserungen durch wiederholte Anfragen die Ergebniskennungen und die angezeigten Assets unabhängig voneinander.

Wechseln Sie zwischen mehreren Abfragen und Zeitachsenbereichen, anstatt ein Element unbegrenzt zu wiederholen. Beziehen Sie ein repräsentatives Leerlaufintervall und eine konkurrierende Arbeitslast ein. Ein Server verfügt dann über eine brauchbare Kapazität, wenn die akzeptable Latenz über die erwartete Arbeitsmenge hinweg bestehen bleibt, nicht nur, wenn ein einzelner heißer Pfad resident bleibt.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Kalte, warme und gestörte Durchläufe gemeinsam ausweisen

Erstellen Sie ein dreiteiliges Testverfahren. Führen Sie den Endpunkt zunächst nach einer dokumentierten Kaltstartbedingung aus. Wiederholen Sie ihn anschließend sofort, ohne die Eingaben zu ändern. Führen Sie danach die erwartete Störung ein – Leerlaufzeit, einen anderen Container oder eine umfangreichere Abfragemenge – und wiederholen Sie den Test. Erfassen Sie den Median und die Latenz im langsamen Randbereich statt nur eines einzelnen Stoppuhrwerts.

Ein Support-Thread zur ersten Suche berichtet von einer anfänglichen Verzögerung von zehn bis fünfzehn Sekunden, gefolgt von nahezu sofortigen Wiederholungen. Das unterstreicht, wie wichtig es ist, beide Verteilungen beizubehalten. Daraus lässt sich keine allgemeingültige Immich-Dauer ableiten; Modellauswahl, Beschleuniger, Speicher, Datenträger und Version können die Differenz erheblich verändern.

Schließen Sie mit zwei Zahlen und einer Grenze ab: typische warme Latenz, typische kalte Latenz und das Ereignis, durch das der warme Zustand verloren geht. Wenn das kalte Verhalten das Ziel des Haushalts überschreitet, halten Sie den erforderlichen Zustand resident oder verbessern Sie diesen Ladepfad. Wenn nur künstliche Kaltstarts fehlschlagen, dokumentieren Sie die akzeptierte Betriebsbedingung.