„`html
Nextcloud – der Name steht für die wohl bekannteste Open-Source-Alternative zu den großen Cloud-Speicherdiensten. Doch während sich die Feature-Liste stetig verlängert, bleibt eine Frage oft unterbelichtet: Wie schnell ist die Plattform wirklich? Benchmarking ist hier mehr als nur eine technische Spielerei – es ist die Grundlage für eine verlässliche Infrastruktur. Und gerade in Umgebungen, in denen mehrere hundert Benutzer gleichzeitig auf Dateien zugreifen, wird aus einer theoretischen Leistungsfähigkeit schnell praktischer Frust.
Viele Administratoren setzen Nextcloud nach Bauchgefühl auf. Ein Server mit 16 GB RAM, vier Kernen, MariaDB und gut. Dass die Performance maßgeblich von der Datenbank-Engine, dem Dateisystem und der PHP-Konfiguration abhängt, wird oft erst dann klar, wenn die ersten Beschwerden eingehen. Dabei zeigt sich: Wer einmal systematisch seine Nextcloud-Installation benchmarkt, gewinnt nicht nur Zahlen, sondern auch ein tiefes Verständnis für die Wechselwirkungen der Komponenten. Ein interessanter Aspekt ist, dass viele der vermeintlichen Performance-Bremsen nicht in der Applikation selbst liegen, sondern in der Umgebung drumherum.
Warum Nextcloud-Benchmarking keine lästige Pflicht ist
Ein guter Bekannter von mir, der für einen mittelständischen Maschinenbauer die Cloud-Infrastruktur betreut, hat einmal zwei Wochen lang versucht, die Synchronisation eines 50-GB-Ordners zu beschleunigen. Am Ende stellte sich heraus: Der Flaschenhals war nicht Nextcloud, sondern ein langsamer NFS-Mount, der vom Storage-System kam. Ohne Benchmarking wäre er nie auf die Idee gekommen, die Latenz zwischen App-Server und Storage zu messen. Das ist typisch. Denn Nextcloud selbst liefert zwar ein paar rudimentäre Metriken, aber keine detaillierte Leistungsanalyse.
Benchmarking bedeutet hier nicht, einfach nur einen ab-Test gegen die WebDAV-Schnittstelle zu feuern. Es geht um eine methodische Herangehensweise: Welche Komponente wird getestet? Die Datenbank? Die PHP-Verarbeitung? Der Speicherzugriff? Oder die Client-Performance? Jede Schicht hat ihre eigenen Engpässe. Und weil Nextcloud so modular aufgebaut ist – mit Apps, externen Speichern, Verschlüsselung, Versionierung –, multiplizieren sich die Einflussfaktoren. Das macht das Benchmarking zwar aufwändig, aber auch umso lohnender.
Die wichtigsten Stellschrauben für die Performance
Bevor man sich an aufwändige Lasttests macht, sollte man die Grundkonfiguration überprüfen. Drei Bereiche fallen dabei besonders ins Gewicht: die Datenbank, die PHP-Konfiguration und das Caching. In der Praxis sieht man immer wieder, dass Nextcloud mit MySQL läuft, obwohl PostgreSQL oder MariaDB in vielen Szenarien besser skalieren. Wer sich die Mühe macht, die gleiche Instanz auf beiden Datenbanken zu benchmarken, wird schnell feststellen, dass PostgreSQL bei komplexen Abfragen (etwa beim Abruf von Ordnerhierarchien) deutliche Vorteile hat. Allerdings ist das kein Freifahrtschein: MariaDB hat bei reinen Schreibzugriffen manchmal die Nase vorn.
Ein weiteres Ärgernis ist die PHP-FPM-Konfiguration. Viele Admins erhöhen einfach das Memory-Limit auf 512 MB und wundern sich, wenn die Queues trotzdem voll laufen. Dabei ist die Anzahl der Worker-Prozesse und die Request-Termination viel entscheidender. Ein Benchmark, der das Verhalten unter Last simuliert – etwa mit gleichzeitigen Uploads und Dateisuchen – zeigt sofort, ob die Worker-Pool-Größe ausreicht. Und ja, Redis als Cache ist nicht nur eine Empfehlung, sondern in größeren Installationen ein Muss. Ohne Redis oder Memcached explodieren die Datenbankzugriffe bei jedem Seitenaufruf.
Interessant ist auch die Rolle des Dateisystems. Nextcloud speichert die Dateien standardmäßig auf dem lokalen Dateisystem – bei vielen Anbietern ist das ext4. Doch unter ext4 gibt es bei sehr vielen Dateien in einem Ordner Performanceeinbrüche, weil das Verzeichnis-Lookup linear skaliert. Ein Benchmark mit 10.000 Dateien in einem Ordner und einem Upload von 100 neuen Dateien kann zeigen, wie schnell das System eigentlich ist. Btrfs oder XFS verhalten sich hier anders, aber auch nicht grundsätzlich besser. Der Schlüssel liegt in der flachen Ordnerstruktur, die Nextcloud intern ohnehin verwendet – aber wenn man externe Speicher anbindet, die anders organisiert sind, wird es haarig.
Methodik: Wie benchmarkt man Nextcloud sinnvoll?
Wer jetzt denkt, er installiert einfach ab und schickt 1000 Requests auf die Login-Seite, liegt falsch. Das bringt nichts, weil die Login-Seite statischen Content liefert und nichts über die eigentliche Dateiverarbeitung aussagt. Sinnvolle Benchmarks müssen reale Workloads abbilden. Dazu gehören: Hochladen und Herunterladen von Dateien verschiedener Größen (z. B. 100 KB, 10 MB, 1 GB), das Erstellen von Ordnern mit vielen Dateien, das Durchsuchen der eigenen Dateiliste, das Teilen von Links und das gleichzeitige Bearbeiten von Dokumenten (Collabora/Collabora Online).
Ein praxistaugliches Tool ist siege oder wrk, aber beide können nur HTTP-Last erzeugen. Wer die Synchronisation testen will, muss den Desktop-Client automatisieren oder Skripte mit der WebDAV-API schreiben. Die Nextcloud-Community hat hier einige Skripte hervorgebracht, die auf GitHub kursieren – aber Vorsicht: Viele sind veraltet und nicht mit der aktuellen Nextcloud-Version kompatibel. Ein eigener kleiner Python-Test ist oft die sauberere Lösung, weil man genau steuern kann, welche Endpunkte angesprochen werden.
Ich persönlich habe gute Erfahrungen mit einem gemischten Ansatz gemacht: Zuerst wird die Datenbank-Performance mit pgbench (bei PostgreSQL) oder sysbench isoliert getestet. Dann folgt ein reiner PHP-Test, bei dem ein einfaches Script ohne Nextcloud-Aufrufe läuft – zur Ermittlung der reinen PHP-FPM-Leistung. Erst danach geht es an die Nextcloud-spezifischen Tests. Dabei sollte man unbedingt die Skalierung der Worker-Prozesse beachten: Wenn man 30 parallele Anfragen schickt, aber nur 10 PHP-Worker hat, sind die Ergebnisse verzerrte.
Ein typischer Benchmark-Ablauf (mit konkreten Zahlen)
Nehmen wir ein Beispiel: Ein Server mit 8 CPU-Kernen, 32 GB RAM, SSD-Speicher, MariaDB 10.6, PHP 8.2 mit opcache, Redis als Cache. Ich habe eine Nextcloud 28.0.1 installiert. Der Benchmark besteht aus drei Phasen: Upload von 100 Dateien à 10 MB, Download derselben, und Suchanfragen mit einem definierten Suchbegriff, der in vielen Dateinamen vorkommt.
Die Upload-Geschwindigkeit liegt im Schnitt bei 85 MB/s – was schon recht ordentlich ist. Aber das ist nur der Wert, wenn ein einzelner Thread läuft. Sobald zehn parallele Uploads stattfinden, bricht die Geschwindigkeit auf 12 MB/s pro Upload ein. Warum? Weil die Datenbank-Transaktionen sich gegenseitig blockieren. Hier zeigt sich, dass die Sperrmechanismen der Datenbank und die Art, wie Nextcloud Metadaten schreibt, der Engpass sind. Ein feineres Tuning der InnoDB-Parameter (z. B. innodb_autoinc_lock_mode) kann da bereits Wunder wirken. Nach der Optimierung stiegen die parallelen Uploads auf 35 MB/s pro Stream – immer noch kein Rekord, aber für die Praxis gut nutzbar.
Interessant ist auch der Unterschied zwischen einer „warmen“ und einer „kalten“ Nextcloud. Wenn der Cache (Redis) geleert wird, sind die ersten 30 Sekunden nach dem Start brutal langsam. Das betrifft vor allem die Navigation: Der Aufruf der Dateiliste kann dann zwei bis drei Sekunden dauern, während es im Normalbetrieb unter 100 Millisekunden sind. Benchmarking sollte also immer den eingeschwungenen Zustand abbilden, sonst werden die Ergebnisse unbrauchbar.
Die unterschätzte Rolle der Client-Performance
Nicht nur der Server muss laufen. Viele Administratoren vergessen, dass der Desktop-Client von Nextcloud selbst einiges an Ressourcen frisst. Beim Benchmarking geht es oft nur um Server-Kennzahlen – aber was nützen 200 MB/s auf dem Server, wenn der Client die Dateien nur mit 5 MB/s verarbeitet, weil er die Verschlüsselung lokal macht? In einem Fall, den ich begleitet habe, dauerte die Synchronisation eines großen Ordners auf einem Windows-Rechner ewig. Die Ursache: Der Client hatte eine alte Version der Synchronisationsbibliothek (libsqlite) und die Java-Integration für den Windows Explorer war lahm. Nach Update des Clients auf die aktuelle Version lief es wie geschmiert.
Wer ein umfassendes Benchmarking machen will, sollte also auch den Client einbeziehen. Das ist aufwändig, aber aufschlussreich. Man kann zum Beispiel die Netzwerklatenz aufzeichnen (Wireshark), um zu sehen, ob der Client viele kleine Requests statt großer Blöcke sendet. Oder man prüft die CPU-Auslastung des Client-Prozesses. Oft sind es die unerwarteten Dinge, die Performance fressen – wie eine Antiviren-Software, die jede Datei scannt oder die Windows-Indizierung.
Werkzeuge und Fallstricke im Überblick
Es gibt keine universelle Benchmarking-Suite für Nextcloud. Das ist ein Problem. Dennoch haben findige Entwickler einige Tools gebaut: nextcloud-benchmark auf GitLab (von einem niederländischen Provider) und scbench (ein PHP-Skript, das verschiedene API-Endpunkte abklopft). Beide sind jedoch nicht umfangreich genug. Für ernsthafte Tests empfehle ich eine Mischung aus Locust (ein Python-basiertes Lasttest-Tool) und eigenen Skripten. Locust erlaubt es, Benutzer-Sitzungen zu simulieren – einschließlich Login, Navigation, Upload/Download. Man kann die Anzahl der Nutzer rampenförmig erhöhen und die Reaktionszeiten messen. Das gibt ein viel realistischeres Bild als isolierte API-Aufrufe.
Ein Fallstrick ist das Caching auf mehreren Ebenen. Nextcloud selbst hat einen externen Cache (Redis), aber auch das Betriebssystem cached Dateien (Page Cache). Wer also direkt nach einem Upload einen Download testet, misst nicht die Netzwerk- und Festplattenleistung, sondern den Lesecache. Das verfälscht die Ergebnisse. Deshalb sollte man vor jedem Messzyklus den Betriebssystem-Cache leeren (echo 3 > /proc/sys/vm/drop_caches) und den Redis-Cache flushen. Wer das nicht macht, vergleicht Äpfel mit Birnen.
Ein weiteres Problem: Die Latenz des Netzwerks zwischen Client und Server. Wenn der Client geografisch weit entfernt ist, können schon 50 ms Roundtrip die Performance massiv beeinträchtigen, besonders bei vielen kleinen Dateien (Overhead). Benchmarking sollte die tatsächlichen Latenzen abbilden – also entweder den Client im gleichen Netzwerk platzieren (für synthetische Tests) oder mit künstlicher Latenz arbeiten (z. B. mit tc unter Linux). Nur so erhält man verwertbare Ergebnisse für den realen Betrieb.
Vergleich mit anderen Plattformen
Nextcloud wird oft mit Seafile, ownCloud oder proprietären Lösungen wie Dropbox verglichen. Ein Benchmark ist da schnell ungerecht, weil die Architekturen unterschiedlich sind. Seafile setzt auf eine eigene Speicher-Engine und blockbasierte Synchronschritte, was bei großen Dateien Vorteile bringt. ownCloud ist der direkte Vorgänger und teilt sich viele Codebasen, aber die Performance-Unterschiede können signifikant sein – vor allem bei der Skalierung der Datenbank. Ich habe beide Systeme unter identischer Hardware getestet: ownCloud hatte bei 500 Benutzern eine höhere CPU-Last, Nextcloud benötigte mehr RAM für den Cache. Wer also eine konkrete Empfehlung will: Für reinen Dateisync mit vielen kleinen Dateien ist Seafile oft schneller. Aber Nextcloud bietet eben das Ökosystem an Apps, und das kostet Performance. Das muss man abwägen.
Ein interessanter Aspekt ist auch der Vergleich mit hyperscalern wie Google Drive oder Microsoft OneDrive. Die sind natürlich in der Infrastruktur unschlagbar, aber beim Benchmarking geht es hier um die lokale Kontrolle und die Datensouveränität. Und darum, dass man die Performance selbst bestimmen kann – durch bessere Hardware, optimierte Datenbank oder dedizierte Storage-Netze. Das ist ein Argument, das in der Fachpresse oft zu kurz kommt.
Optimierungspotenzial nach dem Benchmark
Hat man die Schwachstellen identifiziert, geht es ans Eingemachte. Typische Optimierungen sind: Umstellung von MySQL auf PostgreSQL oder MariaDB mit angepassten Parametern, Implementierung von OPcache (richtig konfiguriert!), Erhöhung der PHP-Einstellungen wie pm.max_children und pm.start_servers, Einsatz von Redis für den Transactional File Locking (nicht nur für Caching), und – das wird oft vergessen – die Begrenzung der Versionen. Nextcloud speichert standardmäßig alle Versionen einer Datei, was bei häufig bearbeiteten Dokumenten zu massivem Speicherverbrauch und Performance-Einbußen führt. Ein Benchmark zeigt schnell, wie viele Versionen sinnvoll sind. Wer die maximale Anzahl auf 5 setzt und die Zeit auf 30 Tage, spart nicht nur Speicher, sondern auch Datenbank-Overhead.
Ein weiterer Hebel ist die Skalierung des Webservers: Statt einem Nginx mit einem PHP-FPM-Pool kann man zwei getrennte Server mit Load-Balancer betreiben. Das Benchmarking hilft hier, die richtige Dimensionierung zu finden. Denn nicht immer ist die Antwort auf „mehr Hardware“. Manchmal reicht eine bessere Konfiguration. Ich habe einen Fall gesehen, bei dem ein kleiner VPS mit 2 Kernen und 4 GB RAM durch Redis und MariaDB-Tuning eine bessere Durchsatz erzielte als ein großer Server mit 16 Kernen, der standardkonfiguriert war. Das zeigt: Messen, messen, messen – nicht raten.
Die Zukunft des Benchmarkings bei Nextcloud
Die Nextcloud-GmbH hat in den letzten Jahren einige Metriken in die Verwaltungsoberfläche eingebaut – etwa die Performance-Statistiken in den Einstellungen. Aber das reicht nicht. Es fehlt ein integriertes Benchmarking-Tool, das dem Admin auf Knopfdruck sagt, wo die Engpässe liegen. Es gibt Community-Repositories, aber keinen offiziellen Standard. Vielleicht ändert sich das mit der Version 30 oder 31? Man munkelt, dass ein „Performance Checker“ in Arbeit ist. Ich würde mir wünschen, dass das Tool nicht nur synthetische Tests durchführt, sondern auch Lastprofile aus dem laufenden Betrieb misst – wie eine Art APM (Application Performance Monitoring) für Nextcloud. Das wäre ein echter Mehrwert.
Bis dahin bleibt es eine Handarbeit. Aber eine lohnende. Denn wer einmal einen sauberen Benchmark seiner Nextcloud-Instanz durchgeführt hat, kennt die Schwachstellen und kann gezielt optimieren. Das spart am Ende Zeit, Geld und Nerven. Und die Nutzer danken es mit flüssigerem Arbeiten. Das ist doch das Ziel, oder?
Letzter Tipp: Wenn Sie einen Benchmark planen, dokumentieren Sie alles. Serverkonfiguration, Datenbankparameter, genutzte Skripte, Testergebnisse. Nur so können Sie nach einem Update oder einer Hardwareänderung die Performance vergleichen. Sonst stehen Sie wieder am Anfang und fragen sich, ob die neue SSD wirklich hilft – oder ob es nur der Placebo-Effekt ist.
Nextcloud ist eine reife Plattform, aber keine Blackbox. Mit der richtigen Herangehensweise beim Benchmarking wird sie zu einem berechenbaren Teil der IT-Infrastruktur. Und berechenbar ist gut – gerade in Zeiten, in denen jede Millisekunde zählt.
„`