Wie viele gleichzeitige Nutzer kann Immich bewältigen, bevor es langsamer wird?

Es gibt keine nützliche universelle Zahl gleichzeitiger Immich-Benutzer, die jeder Heimserver bewältigen kann, denn „ein Benutzer“ kann untätiges Durchsuchen, die Gesichtssuche, einen großen Upload, die Videowiedergabe oder mehrere Hintergrundaufgaben gleichzeitig bedeuten.

Die Kapazität sollte als höchste wiederholbare Haushaltsauslastung gemessen werden, bei der die von Ihnen festgelegten Kriterien für Antwortzeit und Fehler weiterhin erfüllt sind. Ermitteln Sie zunächst eine ruhige Ausgangsbasis, spielen Sie realistische gemischte Aktionen erneut ab, erhöhen Sie die Parallelität in kontrollierten Schritten und beobachten Sie die zuerst ausgelastete Ressource. So erhalten Sie einen belastbaren Kapazitätsbereich für Ihre Hardware und Bibliothek statt eines frei erfundenen Benutzerlimits.

Definieren Sie, was „langsamer werden“ bedeutet, bevor Sie Benutzer zählen

Wählen Sie eine kleine Gruppe für Ihr Zuhause relevanter, für Benutzer sichtbarer Aktionen: die Timeline öffnen, ein älteres Album laden, suchen, Videos wiedergeben und ein Paket hochladen. Legen Sie vor dem Test fest, was als Fehler gilt, etwa eine nicht akzeptable Latenz, Zeitüberschreitungen, fehlgeschlagene Uploads, Wiedergabestörungen oder eine Warteschlange, die weiter wächst, nachdem die Benutzer aufgehört haben.

Vermischen Sie Vordergrund- und Hintergrundarbeit nicht, ohne sie zu protokollieren. Die Erstellung von Vorschaubildern, Videotranskodierung, Gesichtsverarbeitung, Smart Search, Bibliotheksscans, Datenbankwartung und Backups können dieselben CPU-, Speicher-, Festplatten- und Netzwerkressourcen verbrauchen wie aktive Benutzer. Ein Test mit „vier Benutzern“ während eines großen Imports stellt eine andere Arbeitslast dar als vier Personen, die eine fertig eingelesene Bibliothek durchsuchen.

Protokollieren Sie bei jedem Ergebnis die Hardware, die Immich-Version, den Speicherort der Datenbank, den Speichertyp, die Netzwerkverbindung, die Bibliotheksgröße und aktive Hintergrundaufgaben. Ohne diesen Kontext lässt sich eine Zahl zur Parallelität nach einem Upgrade oder mit einem anderen Heimserver nicht sinnvoll vergleichen.

Ermitteln Sie eine Ein-Benutzer-Ausgangsbasis bei kontrollierter Hintergrundarbeit

Beginnen Sie, wenn sich das System in einem bekannten Zustand befindet, und messen Sie eine repräsentative Benutzersequenz. Erfassen Sie neben der Antwortzeit auf dem Client auch die CPU-Auslastung des Servers, den Speicherdruck, die Festplattenlatenz oder -auslastung, den Netzwerkdurchsatz, die Datenbankaktivität und alle Immich-Worker-Warteschlangen, die Sie beobachten können.

Eine Kapazitätsaussage ist nur dann aussagekräftig, wenn Arbeitslast, Testdauer und Erfolgskriterien eindeutig festgelegt sind. Nutzen Sie arbeitslastbasierte Kapazitätstests, um eine Ein-Benutzer-Ausgangsbasis zu speichern, und messen Sie anschließend, wie sich Latenz, Durchsatz und Fehler mit steigender Parallelität verändern.

Wenn ein Benutzer bereits langsam ist, brechen Sie den Parallelitätstest ab. Beheben Sie zuerst den Engpass bei einem einzelnen Benutzer; weitere Sitzungen verstärken lediglich ein bestehendes Speicher-, Datenbank-, CPU-, Netzwerk- oder Konfigurationsproblem und sagen wenig über das tatsächliche Skalierungsverhalten des Servers aus.

Erhöhen Sie die realistische Parallelität in kontrollierten Schritten

Fügen Sie schrittweise Benutzer oder skriptgesteuerte Client-Sitzungen hinzu und halten Sie die Mischung der Aktionen zwischen den Schritten möglichst gleich. Eine sinnvolle Abfolge für einen Haushalt könnte darin bestehen, die aktiven Sitzungen ausgehend von einer kleinen Basis jeweils zu verdoppeln. Die genauen Zahlen sind jedoch weniger wichtig, als ausschließlich die Parallelität zu verändern und die Definition der Arbeitslast konstant zu halten.

Legen Sie vor dem Test Grenzwerte für Latenz, Fehler und Durchsatz fest und verwenden Sie realistische mehrstufige Abläufe, statt einen einzelnen Endpunkt zu bombardieren. Eine realistische Lasttest-Arbeitslast für Immich sollte die Aktionen abbilden, die Ihr Haushalt tatsächlich ausführt, statt wiederholte Anmeldeanfragen als Ersatz für die Kapazität eines Fotoservers zu verwenden.

Lassen Sie jeden Schritt lange genug laufen, damit sich Caches, Warteschlangen, Datenbankverbindungen und der Speicherbedarf stabilisieren. Protokollieren Sie sowohl den Spitzenwert als auch, ob sich das System nach Ende der Belastung wieder erholt. Ein Server, der für einen kurzen Spitzenanstieg akzeptabel aussieht, aber eine wachsende Auftragswarteschlange hinterlässt, liegt für diese Arbeitslast bereits über einem nachhaltigen Niveau.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ermitteln Sie die zuerst gesättigte Ressource

Wenn die Latenz sprunghaft ansteigt, vergleichen Sie den Zeitpunkt mit dem Verhalten der Ressourcen. Eine CPU-Sättigung während der Suche oder des maschinellen Lernens deutet auf Rechenlast hin; hohe Festplattenlatenz bei moderater CPU-Auslastung weist auf den Datenbank- oder Medienspeicher hin; vollständig ausgelastete Netzwerkverbindungen deuten auf Grenzen bei Übertragungen oder beim Fernzugriff hin; zunehmende Datenbankwartezeiten oder Verbindungsdruck weisen auf die Datenebene hin.

Hintergrundaufgaben können das Ergebnis verändern, da Vorschaubilderstellung, Transkodierung, maschinelles Lernen, Scans, Backups oder Wiederholungsschleifen auch dann Ressourcen verbrauchen können, wenn niemand aktiv durch die Bibliothek navigiert. Vergleichen Sie den Test bei kontrollierten Immich-Hintergrundlastbedingungen, damit Sie geplante Arbeiten nicht mit einem niedrigen Benutzerlimit verwechseln.

„Beheben“ Sie Kapazitätsprobleme nicht, indem Sie Fehler mit längeren Client-Zeitüberschreitungen verbergen. Ändern Sie die begrenzende Ressource oder die Arbeitslastrichtlinie – etwa durch die zeitliche Planung schwerer Aufgaben, eine bessere Platzierung des Speichers, weniger gleichzeitige Transkodierungen oder zusätzliche Rechenleistung – und spielen Sie anschließend den exakt fehlgeschlagenen Schritt erneut ab, um nachzuweisen, dass sich der Engpass verlagert hat oder verschwunden ist.

Legen Sie einen praktischen Kapazitätsbereich für den Haushalt fest und testen Sie erneut

Definieren Sie die praktische Kapazität als die höchste getestete Parallelität, bei der alle erforderlichen Benutzerabläufe innerhalb Ihrer zuvor festgelegten Latenz- und Fehlergrenzen bleiben, die Warteschlangen nach dem Test wieder in Richtung Ausgangsniveau zurückkehren und der Host ausreichend Reserven für gewöhnliche Hintergrundarbeit behält. Geben Sie sie als arbeitslastspezifischen Bereich an, nicht als allgemeines Immich-Maximum.

Wiederholen Sie den Grenzschritt mindestens einmal aus einem sauberen, vergleichbaren Zustand und beziehen Sie die Aktionen ein, die zuvor zu einer Verschlechterung geführt haben. Testen Sie anschließend den nächsthöheren Schritt kurz genug, um zu bestätigen, dass die Grenze weiterhin bei derselben Ressource sichtbar wird, ohne das System in eine unkontrollierte Warteschlange oder ein Ereignis mit kritischem Speicherdruck zu treiben.

Führen Sie denselben Test nach größeren Immich-Upgrades, einem Datenbankumzug, Änderungen am Speicher, Hardwareänderungen oder einer deutlichen Vergrößerung der Bibliothek erneut durch. Ihre Kapazitätszahl ist eine Eigenschaft des aktuellen Systems und der aktuellen Arbeitslast; das Beibehalten des Testrezepts ist wertvoller als das Beibehalten einer alten Benutzerzahl.