Nextcloud unter Druck: Warum echtes Benchmarking mehr ist als nur Zahlen sammeln

Es gibt eine seltsame Diskrepanz in der Welt der selbstgehosteten Collaboration-Plattformen. Auf der einen Seite steht der berechtigte Wunsch nach digitaler Souveränität, nach Kontrolle über die eigenen Daten und nach Unabhängigkeit von US-Cloud-Giganten. Auf der anderen Seite herrscht oft eine fast schon naive Vorstellung von der Leistungsfähigkeit der eigenen Infrastruktur. „Läuft doch“, ist der häufigste Satz, den man von Administratoren hört, die eine Nextcloud-Instanz im Keller oder irgendwo im Rechenzentrum betreiben. Doch wie gut läuft es wirklich? Und vor allem: Wo liegen die eigentlichen Grenzen?

Benchmarking von Nextcloud wird oft reduziert auf einfache Lasttests mit einer Handvoll Benutzern. Das ist, als würde man die Tragfähigkeit einer Brücke testen, indem man ein Fahrrad darüber schiebt. Es liefert eine Zahl, aber keine aussagekräftige Erkenntnis über das Verhalten im realen Betrieb – unter Spitzenlast, bei parallelen Dateioperationen, unter Volllast der Datenbank oder beim Ausfall eines Backend-Services.

Dabei zeigt sich gerade bei Nextcloud, dieser Art digitalem Schweizer Taschenmesser, dass die Performance von einem komplexen Geflecht aus Abhängigkeiten bestimmt wird. Die Software selbst ist nur die Spitze des Eisbergs. Darunter liegt eine gewaltige Masse aus konfigurierbaren Komponenten: PHP-FPM-Pools, Opcode-Caches, Datenbank-Optimierungen, Caching-Schichten, Filesystem-Treiber, Objekt-Speicher wie S3 oder Swift, und nicht zuletzt die zugrundeliegende Hardware. Ein interessanter Aspekt ist, dass selbst kleinste Konfigurationsänderungen, etwa an den PHP-Memory-Limits oder den MySQL-Query-Caches, dramatische Auswirkungen auf das Antwortverhalten haben können.

Vom Sinn und Unsinn synthetischer Tests

Der Markt ist voll von Tools, die schnelle Benchmarks versprechen. Apache Bench (ab), Siege, wrk – sie alle können HTTP-Anfragen feuern wie ein Maschinengewehr und messen, wie viele Requests pro Sekunde eine Nextcloud-Instanz verkraftet. Diese Zahlen sind nicht wertlos, aber sie sind irreführend, wenn man sie isoliert betrachtet. Ein statischer, im Opcache vorgehaltener Login-Screen kann Hunderttausende Requests pro Sekunde bedienen. Das sagt nichts darüber aus, wie die Instanz reagiert, wenn 50 Benutzer gleichzeitig eine 2-Gigabyte-Videodatei hochladen, während im Hintergrund die Volltextsuche des OnlyOffice-Integrationsdienstes einen Index durchforstet und die Collabora-Online-Instanz ein Dokument konvertiert.

Echtes, aussagekräftiges Benchmarking muss daher den realistischen Nutzerworkflow abbilden. Es muss Szenarien konstruieren, die den Alltag widerspiegeln: das synchrone Öffnen der Web-Oberfläche am Morgen durch hunderte Mitarbeiter, den Mittagspeak beim Teilen großer Dateien, den abendlichen Backup-Job, der den Objektspeicher belastet. Hier kommen Frameworks wie K6 oder Locust ins Spiel, mit denen sich komplexe User-Journeys scripten und unter Last setzen lassen. Man simuliert nicht nur anonyme Hits, sondern echte Sitzungen mit Login, Navigation, Dateioperationen und API-Aufrufen.

Ein nicht zu unterschätzender Faktor ist dabei die sogenannte „Warm-Up“-Phase. Eine frisch deployede Nextcloud, deren Datenbank-Caches leer sind, deren PHP-Opcache noch nicht gefüllt ist, performt kläglich. Ein guter Benchmark muss diese Phase entweder überspringen oder explizit als Teil des Tests ausweisen. Die stabilen Werte, die nach Minuten oder gar Stunden unter konstanter Last erreicht werden, sind die einzig relevanten.

Die Achillesfersen: Datenbank, Dateisystem und Caching

Architektonisch betrachtet ist Nextcloud eine dreistöckige Anwendung. Ganz oben agiert der PHP-Application-Layer, darunter sitzt die Datenbank als zentraler Zustandsspeicher für Metadaten, und am Boden liegt der eigentliche Dateispeicher. Jede dieser Schichten kann zum Flaschenhals werden.

Beginnen wir mit der Datenbank. Standardmäßig setzt Nextcloud auf MySQL oder MariaDB. Jede Aktion – eine geteilte Datei, eine Kalendereintrag, eine Chat-Nachricht in Talk – generiert eine Vielzahl von Datenbank-Operationen. Unter Last entstehen Lock-Konflikte. Die Tabelle `oc_filecache` beispielsweise, das Herzstück der Dateimetadaten, wird bei intensiver Nutzung zum ständigen Krisenherd. Ein Benchmark, der das nicht berücksichtigt, ist nutzlos. Entscheidend sind Metriken wie die Query-Latency, die Anzahl der slow queries und der Anteil der Timeouts auf Datenbankebene. Nicht selten ist der Wechsel von einer einfachen lokalen MySQL-Instanz zu einem gut konfigurierten MariaDB-Galera-Cluster oder sogar zu PostgreSQL (was Nextcloud ebenfalls unterstützt) der größte Performance-Hebel überhaupt.

Das Dateisystem ist der nächste Kandidat. Die klassische Installation speichert Dateien einfach im lokalen Dateisystem unter `data/`. Bei zehntausenden kleinen Dateien – Think Office-Dokumente, PDFs – kommt es zu Inode-Problemen, die Performance bricht ein. Moderne Setups lagern deshalb die Binärdaten in einen S3-kompatiblen Objektspeicher wie MinIO, Ceph oder einen kommerziellen Anbieter aus. Das entlastet den App-Server enorm, verlagert die Last aber auf die Netzwerklatenz und die Performance des Objektspeichers. Ein Benchmark muss also auch die PUT-/GET-Geschwindigkeit und die Konsistenz des Object Storage prüfen.

Die dritte kritische Schicht ist das Caching. Nextcloud besitzt einen integrierten Distributed Memory Cache, der üblicherweise mit Redis oder Memcached realisiert wird. Dieser Cache hält Sitzungsdaten, App-Konfigurationen und häufig abgefragte Metadaten vor. Die falsche Größe, eine ineffiziente Netzwerkkonfiguration oder ein träger Redis-Server können die gesamte Anwendung ausbremsen. Ein sinnvoller Test misst die Cache-Hit-Ratio und die Latenz der Cache-Zugriffe.

Die unterschätzte Kunst der Metrik-Auswahl

Was misst man also? Die naive Antwort „Requests pro Sekunde“ ist, wie wir festgestellt haben, unzureichend. Ein ausgereiftes Benchmarking-Setup konzentriert sich auf nutzerzentrierte Metriken.

Die Latenz der Seitenladezeiten aus Nutzersicht ist der wichtigste Indikator. Wie lange dauert es, bis der Dashboard-Tab nach dem Login vollständig interaktiv ist? Tools wie Sitespeed.io oder sogar einfache Browser-Automation mit Playwright können diese „Time to Interactive“ messen. Entscheidend sind die P95- und P99-Perzentile. Wenn die durchschnittliche Ladezeit bei 1,2 Sekunden liegt, die letzten 5% der Anfragen aber 12 Sekunden benötigen, haben Sie ein massives Problem, das im Mittelwert völlig untergeht.

Die Durchsatzrate bei Dateioperationen ist ein weiterer Kernwert. Dabei geht es nicht nur um rohe Übertragungsgeschwindigkeit (MB/s), die oft von der Netzwerkleitung begrenzt wird. Viel entscheidender ist die Anzahl der parallelen Transfers, die das System verarbeiten kann, und die Stabilität der Geschwindigkeit über die Zeit. Bricht der Durchsatz ein, wenn hundert kleine Dateien gleichzeitig hochgeladen werden? Das deutet auf einen Engpass im Datenbank-I/O oder im Filesystem-Locking hin.

Die Skalierbarkeit vertikal und horizontal muss quantifiziert werden. Wie verhält sich die Instanz, wenn man den Arbeitsspeicher der App-Server verdoppelt (vertikale Skalierung)? Oder wenn man einen zweiten, dritten, vierten Nextcloud-App-Server hinter einem Load Balancer einfügt (horizontale Skalierung)? Hier stößt man schnell an die Grenzen der zentralen Datenbank. Ein Benchmark sollte zeigen, ab welchem Punkt das Hinzufügen weiterer App-Server keinen nennenswerten Gewinn mehr bringt – das ist die effektive Skalierbarkeitsgrenze der aktuellen Architektur.

Schließlich sind Stabilitäts- und Degradationsmetriken unter Dauerlast unerlässlich. Wie verhält sich das System nach sechs Stunden konstanter Belastung auf 80% der ermittelten Maximalkapazität? Tritt Memory-Leaking in den PHP-Prozessen auf? Füllen sich die Datenbank-Connection-Pools? Diese Ausdauertests (Soak Tests) offenbaren Probleme, die in einem kurzen, zehnminütigen Stresstest niemals sichtbar werden.

Praxistest: Ein beispielhaftes Benchmark-Setup

Theorie ist schön und gut, aber wie baut man so etwas auf? Nehmen wir ein fiktives, aber realistisches Szenario an: Ein mittelständisches Unternehmen mit 500 Mitarbeitern plant die Migration von einem alten Fileserver auf Nextcloud. Die IT-Abteilung will wissen, ob die geplante Infrastruktur – zwei virtuelle App-Server mit 8 Kernen und 32 GB RAM, eine HA MariaDB-Cluster, ein separater MinIO-Cluster für Objektspeicher – ausreicht.

Zuerst definiert man die User-Journeys. Journeys sind:
1. Der Standard-Workflow: Login, Dashboard aufrufen, durch Dateien navigieren, eine 5-MB-PDF herunterladen.
2. Der Kollaborations-Workflow: Eine .docx-Datei in OnlyOffice öffnen, bearbeiten, speichern, teilen.
3. Der Massenupload: 50 Bilddateien à 10 MB aus einem Verzeichnis hochladen.
4. Die Suche: Eine globale Volltextsuche nach einem bestimmten Begriff in allen eigenen Dateien.

Diese Journeys werden in ein K6-Skript gegossen. Man startet mit einer sanften Rampe von 10 virtuellen Usern (VUs) auf 100 über 10 Minuten. Man misst dabei nicht nur die Serverantwortzeiten, sondern auch systemseitig via Prometheus und Grafana die Auslastung der einzelnen Komponenten: CPU-Wartezeit auf I/O auf den App-Servern, MySQL-Thread-Queue, Netzwerkauslastung zum MinIO-Cluster, Auslastung des Redis-Caches.

Die erste Erkenntnis ist oft ernüchtern: Schon bei 50 parallelen Usern schießt die Latenz des Logins in die Höhe. Die Ursache findet sich in den Grafana-Dashboards: Die Datenbank ist der Engpass. Die Query für die Benutzersession (`oc_users`-Tabelle) wird langsam. Abhilfe schafft hier ein gezielter Index oder die Aktivierung des persistenten Database-Layer-Caching in der Nextcloud-Konfiguration.

Nach dieser Optimierung wird der Test wiederholt. Nun schafft das System 200 VUs, bevor die Datei-Operationen zum Problem werden. Die Upload-Geschwindigkeit bricht ein. Die Metriken zeigen, dass die PHP-FPM-Prozesse auf den App-Servern auf die Disk-I/O warten – obwohl die Dateien doch in MinIO gespeichert werden sollen. Der Fehler liegt in der Konfiguration: Der `primary object storage` ist aktiviert, aber der lokale Temporär-Cache (`tempdirectory`) liegt auf einer langsamen VM-Disk. Die Lösung ist, dieses Temp-Verzeichnis auf eine RAM-Disk (tmpfs) zu legen. Schon verbessert sich der Durchsatz um das Dreifache.

Dieses iterative Vorgehen – testen, messen, Engpass identifizieren, optimieren, wieder testen – ist der Kern eines professionellen Benchmarks. Es ist ein zyklischer Prozess, kein einmaliges Ereignis.

Die Fallstricke und häufigen Fehler

Bei aller Systematik lauern Fallstricke. Der häufigste Fehler ist das Benchmarking in der Produktivumgebung. Selbst vermeintlich sanfte Lasttests können Caches verdrängen, Logdateien fluten und die echten Nutzer stören. Ein exakter Clone der Produktivsysteme – inklusive anonymisierter Datenbestände – in einer isolierten Testumgebung ist unabdingbar. Das ist aufwändig, aber alternativlos.

Ein weiterer Fehler ist die Vernachlässigung des Client-Verhaltens. Nextcloud wird selten nur über den Browser genutzt. Die Desktop- und Mobile-Clients synchronisieren kontinuierlich im Hintergrund und erzeugen eine ganz andere, dauerhafte Last als sporadische Web-Zugriffe. Ein guter Benchmark simuliert daher auch eine Basislast von synchronisierenden Clients, über die dann die Spitzen der interaktiven Nutzung gelegt werden.

Schließlich das Problem der Reproduzierbarkeit. Ein Benchmark ist nur dann wissenschaftlich haltbar, wenn er unter exakt denselben Bedingungen wiederholbar ist. Das bedeutet: Container-Images mit fester Version, automatisiertes Provisioning der Infrastruktur mit Ansible oder Terraform, und die protokollgenaue Dokumentation jedes Testlaufs. „Bei uns ging es letzte Woche viel schneller“ ist kein hilfreicher Kommentar, wenn man nicht weiß, was sich geändert hat.

Beyond the Basics: Spezialfälle und Edge-Szenarien

Wer die Grundlagen im Griff hat, kann sich den spezielleren Szenarien widmen. Wie verhält sich Nextcloud, wenn integrierte Dienste wie **Collabora Online**, **OnlyOffice** oder der **Talk**-Messenger aktiv sind? Diese sind oft ressourcenhungrige externe Services, die über die Nextcloud-API angebunden sind. Ein Leistungstest muss hier die gesamte Kette betrachten. Die Latenz einer Dokumentenbearbeitung setzt sich zusammen aus der Nextcloud-Antwortzeit, der Renderzeit in Collabora und der Netzwerklatenz dazwischen.

Ein weiteres, oft übersehenes Szenario ist das **Benutzer-Onboarding**. Was passiert, wenn am ersten Tag eines neuen Projekts 100 neue Accounts angelegt und diese erstmalig mit jeweils 20 GB Grunddaten befüllt werden? Dieser initiale Datensturm stellt eine extreme Belastung für den Objektspeicher und die Datenbank dar und kann das System für alle anderen Benutzer zum Erliegen bringen. Hier helfen gezielte Rate-Limits und die Planung von Onboarding-Wellen.

Nicht zuletzt sollte man die **Wiederherstellungsgeschwindigkeit** nach einem Ausfall benchmarken. Wie lange dauert es, bis nach einem Neustart des gesamten Clusters die ersten Nutzer sich wieder einloggen können? Wie verhält sich die Performance, während die Caches sich langsam wieder füllen? Diese „Cold Start“-Szenarien sind für die Definition realistischer Recovery Time Objectives (RTO) essentiell.

Tools der Wahl: Mehr als nur Hammertests

Die Tool-Landscape für solch tiefgehende Analysen ist vielfältig. Für synthetische Last ist **K6** von Grafana Labs aktuell der Favorit vieler Profis. Es ist scriptbar in JavaScript, kann komplexe Abfolgen abbilden und liefert metrische Daten direkt an InfluxDB oder Prometheus. Für eher klassische, auf Python basierende Ansätze ist **Locust** eine sehr mächtige Alternative.

Für die Analyse der Infrastruktur ist ein **Prometheus/Grafana**-Stack nahezu Standard. Die Nextcloud-App selbst bietet eine integrierte Monitoring-API, die viele interne Metriken ausspielt. Diese sollte man ergänzen durch Exporters für das Betriebssystem (node_exporter), die Datenbank (mysqld_exporter), Redis (redis_exporter) und den Objektspeicher (minio_exporter oder der jeweilige Cloud-Anbieter).

Für die Profilierung des PHP-Codes selbst, also um herauszufinden, welche Funktionen unter Last die meiste Zeit beanspruchen, braucht es Tools wie **Blackfire.io** oder **Tideways**. Sie instrumentieren die Laufzeitumgebung und zeigen Hotspots im Application-Code an – oft findet man so ineffiziente Nextcloud-App-Erweiterungen oder suboptimale Datenbank-Abfragen in den Core-Klassen.

Fazit: Benchmarking als strategische Disziplin

Nextcloud-Benchmarking sollte nicht als lästige Pflichtübung vor der Go-Live-Entscheidung gesehen werden. Es ist eine kontinuierliche, strategische Disziplin. In einer Welt, in der digitale Kollaboration zur kritischen Infrastruktur wird, ist das Wissen um die eigenen Grenzen überlebenswichtig.

Ein durchdachtes Benchmarking-Programm liefert die Datenbasis für fundierte Investitionsentscheidungen. Brauchen wir mehr RAM oder schnellere CPUs? Lohnt sich der Wechsel zu einem teureren, aber leistungsfähigeren Datenbank-Cluster? Reicht unsere Internet-Anbindung für die geplante externe Nutzung? All diese Fragen lassen sich nicht aus dem Bauch heraus, sondern nur auf Basis belastbarer Messdaten beantworten.

Am Ende geht es nicht darum, die höchste Zahl in einem künstlichen Test zu erreichen. Es geht darum, ein klares, vorhersagbares und robustes Leistungsprofil für die eigene Nextcloud-Instanz zu haben. Um sicherzustellen, dass die Plattform nicht nur „läuft“, sondern unter realen Bedingungen stabil, schnell und zuverlässig ihren Dienst tut. Das ist der eigentliche Wert der Arbeit – und der Grund, warum sich der Aufwand für ein echtes, tiefgehendes Benchmarking immer lohnt.

Die Alternative ist das Arbeiten auf Basis von Vermutungen und das reagieren auf Krisen, wenn die Nutzer schon wütend sind. In der IT, wie in vielen anderen Bereichen auch, gilt: Wer misst, misst Mist. Aber wer nicht misst, managt im Blindflug.