So messen Sie die Immich-Leistung, ohne Cache mit Kapazität zu verwechseln

Die Kapazität von Immich sollte anhand wiederholter kalter, warmer und anhaltender Workloads gemessen werden, da ein einzelner schneller Lauf mit Cache die tatsächliche Sättigungsgrenze des Systems verschleiern kann.

Ein Heimserver kann eine Zeitleiste oder ein Album extrem schnell wirken lassen, nachdem dieselben Vorschaubilder, Datenbankseiten und Anwendungsdaten bereits verwendet wurden. Dieses Ergebnis zeigt, dass der warme Pfad effizient ist – nicht, dass das System eine größere Familienbibliothek oder mehr gleichzeitige Aktivitäten dauerhaft bewältigen kann. Ein sinnvoller Kapazitätstest muss den Cache-Zustand kontrollieren, die Arbeitsmenge vergrößern, die Läufe wiederholen und eine messbare Abbruchbedingung festlegen.

Cache-Geschwindigkeit ist nicht dasselbe wie Kapazität

Kapazität beschreibt, wie viel repräsentative Arbeit ein Immich-System dauerhaft bewältigen kann, bevor Latenz, Warteschlangen oder Fehler nicht mehr akzeptabel sind. Cache-Geschwindigkeit beantwortet eine engere Frage: Wie schnell kann das System Arbeit wiederholen, nachdem relevante Daten oder erzeugte Assets bereits griffbereit sind? Wenn ein Benchmark dasselbe Album oder dieselbe Zeitleiste wiederholt, können diese beiden Fragen identisch wirken, obwohl sie unterschiedliche Betriebsbedingungen messen.

Der Unterschied ist bei der Web-Performance leicht zu erkennen, wenn sich die Zeiten für den ersten und wiederholten Seitenaufruf unterscheiden, weil spätere Anfragen zwischengespeicherte Ressourcen wiederverwenden. Bei Immich gibt es zusätzliche Möglichkeiten für ein warmes Verhalten, da Vorschaubilder, Previews, Datenbankseiten, Dateisystem-Metadaten, der Cache des Betriebssystems und Client-Assets wiederverwendet werden können. Ein wiederholter Lauf kann daher Arbeit auslassen, die eine wachsende oder neu aufgerufene Bibliothek weiterhin erledigen muss.

Aus demselben Grund kann ein cacheorientierter Home-Assistant-Test irreführend sein, wenn wiederholte Anfragen den Großteil der Stichprobe ausmachen; die Diskussion von ZimaSpace über Cache-Ebenen bei wiederholten Anfragen lässt sich auf die Messlogik hier übertragen. Bei Immich sollte die warme Performance aufgezeichnet, aber als separater Pfad gekennzeichnet werden, statt sie als allgemeine Kapazität des Servers zu betrachten.

Kalte, warme und eingeschwungene Läufe trennen

Definiere zunächst den Zustand, bevor du die Stoppuhr startest. Ein kalter Lauf sollte Arbeit umfassen, die nicht gerade wiederholt wurde, etwa das Öffnen eines anderen Datumsbereichs oder Asset-Sets, nachdem Caches weniger Gelegenheit hatten zu helfen. Ein warmer Lauf wiederholt bewusst einen bekannten Pfad. Ein Lauf im eingeschwungenen Zustand hält repräsentative Aktivität lange genug aufrecht, um Hintergrundarbeit, Ressourcenwiederverwendung und Warteschlangen sichtbar zu machen, die ein kurzer Burst möglicherweise nie offenlegt.

Auch das Aufwärmen selbst kann täuschen. Percona beschreibt Fälle, in denen eine Datenbank bereits aufgewärmt zu sein scheint, während verzögerte Hintergrundprozesse die Performance weiter verändern. Daher wird der eingeschwungene Zustand später erreicht als bei den ersten schnellen Abfragen. Auch bei Immich können je nach Aktivität der Bibliothek gerade Datenbankaktivitäten, Vorschaubildverarbeitung, Indexierung oder andere Warteschlangenjobs parallel zum Browsen im Vordergrund laufen.

Führe für einen Heimserver-Test jede Phase separat aus, statt sie zusammen zu mitteln. Notiere, ob Hintergrundjobs inaktiv oder aktiv sind, halte Client und Netzwerkpfad konstant und wiederhole dieselbe Phase mehrmals. Wenn der warme Lauf schnell ist, die anhaltende Aktivität jedoch allmählich Latenz oder Warteschlangentiefe erhöht, ist das zweite Ergebnis das bessere Signal für die Kapazitätsplanung.

Die Arbeitsmenge größer als den leicht cachbaren Bereich machen

Ein Benchmark, der dieselben zwanzig Fotos öffnet, ist normalerweise zu klein, um die Kapazität einer Familienbibliothek zu beurteilen. Betriebssystem, Datenbank, Client und Speicherschicht können einen kleinen aktiven Datensatz nahe am Prozessor halten, während die reale Nutzung zwischen Monaten, Personen, Alben, Suchergebnissen und Videos wechselt. Die Testmenge sollte daher groß und vielfältig genug sein, dass nicht jeder Vorgang von denselben kürzlich verwendeten Daten profitiert.

Die Praxis des Datenbank-Benchmarkings macht den Unterschied deutlich: Wenn ein Test Speicher- oder kaltes Verhalten untersuchen soll, kann ein verbliebener Cache die Übung stattdessen in einen Test der Cache-Performance verwandeln. Du musst nicht jede Cache-Ebene auf einem produktiven Immich-Server leeren, um nützliche Erkenntnisse zu gewinnen. Du brauchst jedoch eine Arbeitslast, deren Arbeitssatz über eine einzelne, wiederholt verwendete Ansicht hinausgeht.

Wähle mehrere Datumsbereiche, Alben, Suchanfragen und Asset-Typen, die der normalen Nutzung im Haushalt entsprechen, und wechsle zwischen ihnen, statt eine einzige Ansicht ununterbrochen aufzurufen. Behalte diese Arbeitslastdefinition bei Vergleichen von Hardware oder Konfigurationen bei. Wenn eine Änderung nur eine kleine, wiederholte Teilmenge verbessert, die Navigation über größere Bereiche unter Last jedoch weiterhin schlechter wird, hat sie den heißen Pfad verbessert, ohne die nützliche Kapazitätsgrenze zu verschieben.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Perzentile messen und den Test wiederholen

Ein einzelner Durchschnitt kann die Momente verbergen, die Nutzer tatsächlich bemerken. Wenn neun Anfragen schnell sind und die zehnte blockiert, während sich eine Warteschlange bildet oder der Speicher stark ausgelastet ist, kann der Mittelwert noch immer ordentlich aussehen. Zeichne mindestens das Verhalten des Medians und ein Perzentil der Randverteilung wie p95 auf. Kombiniere die Latenz anschließend mit Durchsatz, Fehleranzahl, Rückstand an Jobs, CPU-Auslastung, Speicherdruck und Speicheraktivität, damit die Verlangsamung in ihren Kontext eingeordnet werden kann.

Eine praktische Benchmark-Analyse empfiehlt, p50, p95, p99 und die Varianz zu melden, statt einer einzelnen Ausführung zu vertrauen – besonders bei zustandsbehafteten Systemen, bei denen Cache-Verdrängung, Kompaktierung oder Hintergrundaktivität erst später auftreten können. Immich-Tests müssen keine Laborpräzision erreichen, benötigen aber genügend Wiederholungen, um eine reproduzierbare Grenze von einem zufällig ruhigen Zeitraum zu unterscheiden.

Führe dasselbe Szenario bei jeder Laststufe mindestens mehrmals aus und bewahre die Rohbeobachtungen auf, statt nur den besten Durchlauf zu behalten. Eine Kapazitätsaussage wird glaubwürdiger, wenn p95 über mehrere Läufe stabil bleibt und der Server aufgestaute Arbeit zwischen den Messfenstern abarbeiten kann. Wenn die Ergebnisse stark schwanken, untersuche zunächst die unkontrollierte Variable, bevor du erklärst, dass mehr Benutzer, mehr Fotos oder schnellere Hardware die Obergrenze verändert haben.

Ein Immich-Kapazitätsprotokoll mit Abbruchbedingung verwenden

Beginne mit einer repräsentativen Client-Arbeitslast und erfasse eine Ausgangsbasis, nachdem das System den Zustand erreicht hat, den du testen möchtest. Erhöhe anschließend jeweils nur eine Variable: mehr gleichzeitiges Browsen, mehr Uploads, mehr Suchanfragen oder mehr Hintergrundverarbeitung, während Bibliothek, Client-Mix, Netzwerkpfad und Serverkonfiguration unverändert bleiben. Erfasse bei jedem Schritt p50- und p95-Latenz, erfolgreiche Vorgänge pro Minute, Fehler, das Wachstum der Warteschlangen und die wichtigste Serverressource, die sich der Sättigung nähert.

Dieser Ansatz vermeidet den häufigen Fehler, aus einem einzigen kurzen Durchlauf Schlussfolgerungen zu ziehen. Hinweise zum Performance-Testing warnen vor Schlussfolgerungen aus einem einzelnen Lauf, da Aufwärmphase, Cache-Zustand, Hintergrundarbeit und normale Systemschwankungen eine Stichprobe dominieren können. Wiederhole jede Laststufe, bis die Entwicklung stabil genug ist, um sie zu erklären – nicht nur bequem genug, um sie zu zitieren.

Lege vor dem Test eine Abbruchregel fest. Eine praktische Heuristik für das Heimlabor besteht darin, die aktuelle Konfiguration als gesättigt zu betrachten, wenn die p95-Latenz in drei aufeinanderfolgenden Messfenstern dauerhaft über ungefähr dem Doppelten der unbelasteten Ausgangsbasis liegt oder wenn Fehler oder Job-Rückstand weiter wachsen, statt sich abzubauen; dies ist eine Testheuristik und keine Immich-Grenze. Die nützliche Kapazitätszahl ist die letzte Laststufe unterhalb dieser Grenze, gemessen mit demselben Protokoll für kalte, warme und eingeschwungene Läufe.