„`html
Wer eine eigene Nextcloud betreibt, kennt das Szenario: Die ersten Monate läuft alles rund, dann meckern die ersten Anwender. Das Hochladen großer Ordner dauert ewig, die Oberfläche reagiert träge, und der Kalender braucht gefühlt eine halbe Ewigkeit, bis er sich synchronisiert. Oft ist die Ursache nicht die Software selbst, sondern ein Mangel an grundlegender Pflege und Optimierung. Dabei ist Nextcloud ein beeindruckendes Stück Software, das in seiner Flexibilität kaum Wünsche offen lässt. Doch genau diese Flexibilität bringt eine Komplexität mit sich, die man ernst nehmen muss, will man das System für den produktiven Einsatz rüsten.
Dieser Artikel richtet sich an alle, die nicht nur nebenbei eine Instanz für Freunde betreiben, sondern eine ernsthafte Plattform für ihr Unternehmen oder eine anspruchsvolle Nutzergruppe bereitstellen möchten. Es geht nicht um simple Listen mit „Tuning-Tipps“, sondern um ein Verständnis für die Zusammenhänge hinter der Performance. Wir sprechen über Architektur, über das Zusammenspiel von PHP, Datenbank und Webserver, über Caching und über die oft unterschätzte Rolle des Dateisystems. Dazu kommen praktische Hinweise zur Skalierung – und ein ehrlicher Blick auf die Fallstricke, die einen auch dann noch erwischen können, wenn man eigentlich alles richtig gemacht hat.
Das Fundament: Architektur ist keine Geschmacksfrage
Bevor man sich mit Opcache-Einstellungen oder Redis-Konfigurationen beschäftigt, sollte man die Grundsatzfrage klären: Wie ist die Instanz überhaupt aufgebaut? Viele Probleme lassen sich auf einen einzelnen Webserver mit einer SQLite-Datenbank zurückführen. Das funktioniert für eine Handvoll Nutzer, spätestens bei zehn gleichzeitigen Sessions wird es aber kritisch. Nextcloud selbst weist darauf hin, dass SQLite nicht für den Produktivbetrieb vorgesehen ist – doch die Einfachheit verführt dazu.
Als Faustregel gilt: Wer mehr als ein paar Benutzer bedient, benötigt eine saubere Trennung von Webserver, Datenbank und Storage. Dabei ist es zweitrangig, ob man diese Trennung mit Docker-Containern, virtuellen Maschinen oder gleich mit dedizierter Hardware umsetzt. Entscheidend ist, dass die einzelnen Komponenten unabhängig voneinander verwaltet und skaliert werden können. Die gute Nachricht: Nextcloud lässt sich in nahezu beliebigen Topologien betreiben, von der monolithischen Installation auf einem einzelnen Mini-PC bis hin zum hochverfügbaren Cluster. Die schlechte Nachricht: Diese Freiheit führt dazu, dass viele Betreiber sich für die vermeintlich einfache Lösung entscheiden und später vor massiven Performance-Problemen stehen.
Ein interessanter Aspekt ist dabei die Wahl der Datenbank. PostgreSQL gilt unter Nextcloud-Enthusiasten seit Langem als die solideste Option, was Performance und Datenintegrität angeht. MySQL und MariaDB funktionieren zwar ebenfalls, offenbaren jedoch bei komplexen Abfragen und unter hoher Last ihre Schwächen. Wer die Wahl hat, sollte also seriös testen, statt sich für das zu entscheiden, was im jeweiligen Linux-Repository zufällig als Standard installiert ist. In den meisten Fällen ist PostgreSQL die vernünftige Alternative. Nicht zuletzt, weil die Datenbank nicht nur für Metadaten zuständig ist, sondern auch für die Föderation und die Gruppierung von Dateien – ein Bereich, der gerne unterschätzt wird.
Weiterhin sollte man die Möglichkeit in Betracht ziehen, die Nextcloud-eigene Datenbank von vorneherein von Diensten wie dem Volltextsucher oder der Benutzerverwaltung zu entkoppeln. Ein eigener Elasticsearch- oder Apache-Solr-Server entlastet die Datenbank erheblich, sobald umfangreiche Dateisuche oder bestimmte App-Funktionen zum Einsatz kommen. Das ist nicht immer trivial einzurichten, zahlt sich aber aus, sobald die Dateianzahl in die Zehntausende geht. Dabei zeigt sich eines sehr deutlich: Nextcloud ist weniger ein „Dateisynchronisations-Tool“ als vielmehr eine Plattform, die durch ihre Module und Schnittstellen lebt. Je stärker man diese ausbaut, desto wichtiger wird eine solide, skalierbare Architektur.
Hardware: Mehr RAM schadet nie – aber es reicht nicht
Beginnen wir mit einer Binsenweisheit: Nextcloud frisst Arbeitsspeicher. Das liegt nicht allein an PHP, sondern auch an den eingebundenen Daemons für Hintergrundjobs und der Datenbank. Eine Instanz mit 20 Benutzern und einigermaßen aktiver Nutzung sollte schon mit acht Gigabyte RAM rechnen, wenn man nicht ständig in den Swap-Bereich ausweichen möchte. 16 Gigabyte sind besser, und bei Verwendung von Docker kommen ohnehin noch Overhead und die mehr oder weniger speicherhungrigen Container hinzu. Doch wer glaubt, mit einem übertakteten Prozessor und viel RAM allein alle Probleme zu lösen, irrt. Die I/O-Leistung der Festplatten oder SSDs ist oft der eigentliche Flaschenhals.
Eine einfache Messung mit iotop oder iostat zeigt in den meisten Problemfällen, dass die Latenzen bei den Lese- und Schreibzugriffen hoch sind – gerade dann, wenn viele kleine Dateien verarbeitet werden. Hier hilft es ungemein, die Nextcloud-Daten auf schnellen NVMe-SSDs abzulegen, während die Metadaten der Datenbank auf einer separaten Festplatte oder einer eigenen Partition liegen. Das klingt nach Luxus, ist aber für einen reibungslosen Betrieb fast schon notwendig. Die Praxis zeigt: Sobald mehrere Benutzer gleichzeitig Dateien synchronisieren, kommt ein einzelnes NAS-Laufwerk schnell an seine Grenzen, weil es die vielen parallelen Zugriffe nicht gewohnt ist.
Dazu kommt der Netzwerk-Aspekt. Eine gute Server-Hardware nützt wenig, wenn die Anbindung über einen 1-Gbit/s-Switch erfolgt und dieser gleichzeitig den gesamten Büroverkehr schlucken muss. Auch wenn es nicht direkt mit Nextcloud zu tun hat: Eine eigene Verbindung zwischen Server und Storage, gegebenenfalls über iSCSI oder NFS, kann Wunder bewirken. Wichtig ist dabei, die Latenzen im Blick zu behalten. Nextcloud ist im Gegensatz zu manchen anderen Produkten empfänglich für kleine Verzögerungen bei Verbindungen zu den Storage-Backends – und dann zeigen die Client-Apps ein unschönes Verhalten mit wiederholten Timeouts und abgebrochenen Uploads.
Ein weiterer Punkt, der oft unterschätzt wird: die Anzahl der gleichzeitigen Verbindungen. Ein einzelner Webserver wie Apache oder Nginx hat seine eigene maximale Verbindungszahl, und Nextcloud braucht pro Client-Prozess oft mehrere Verbindungen. Wenn also 50 Benutzer gleichzeitig synchronisieren, kann das den Server in die Knie zwingen, obwohl die CPU nur müde vor sich hin dümpelt. Hier ist es hilfreich, die Worker-Prozesse zu erhöhen und den Server nicht mit anderen Diensten zu teilen – oder zumindest die Last mit einem Reverse-Proxy sauber zu verteilen.
Die Hardware-Frage ist also nicht mit einer simplen „je mehr, desto besser“-Antwort erledigt. Es braucht ein gewisses Gespür dafür, welche Komponente unter welcher Last leidet. Deshalb empfehle ich jedem Betreiber, von Anfang an ein Monitoring einzurichten. Wer erst nachts um drei aufwacht, weil der Server nicht mehr reagiert, handelt reaktiv. Wer die Daten von CPU, RAM, I/O und Netzwerk über Wochen sammelt, erkennt Muster und kann proaktiv eingreifen. Das ist kein Hexenwerk, verlangt aber ein wenig Disziplin und die Bereitschaft, sich in Tools wie Grafana oder Prometheus einzuarbeiten.
Das Betriebssystem: Linux ist nicht gleich Linux
Die Wahl der Server-Distribution ist meistens eine Frage der persönlichen Vorliebe oder der Unternehmenspolitik. Debian, Ubuntu, RHEL-Klone – am Ende läuft Nextcloud überall. Aber es gibt durchaus Unterschiede, die bei der Performance eine Rolle spielen. Nicht jeder Kernel ist für Netzwerk- oder Dateisystemlast gleich gut optimiert. Dazu kommen die Versionen der Pakete: Wer mit einem alten Ubuntu LTS arbeitet, hat oft eine veraltete PHP-Version und muss händisch aktualisieren, was schnell zu Brüchen führen kann.
Ein ehrlicher Rat: Wer nicht zwingend auf die Standard-Pakete des Distributors angewiesen ist, sollte auf PHP in einer aktuellen Version setzen. Nextcloud arbeitet mit PHP 8.x deutlich besser als mit den alten 7.4-Zeiten. Die Performance-Unterschiede sind nicht marginal – gerade bei der Ausführung von komplexen Skripten zeigt sich ein spürbarer Gewinn. Außerdem verbessert PHP 8 die Fehlerbehandlung und den Umgang mit Speicher, was sich in stabileren Prozessen niederschlägt.
Was mich immer wieder verwundert, ist die Vernachlässigung der Systemdateien und der Berechtigungen. Nextcloud besteht aus Tausenden von PHP-Dateien, und wenn der Webserver nicht richtig auf diese Dateien zugreifen kann, führt dies zu unerklärlichen Lags. Dabei hilft es nicht, einfach chmod -R 777 zu setzen – das ist eher ein Sicherheitsrisiko. Stattdessen sollte man die Dateien dem richtigen Benutzer zuweisen und mit chattr oder ähnlichen Mechanismen arbeiten. Ein gut konfigurierter Opcache kann ebenfalls helfen, den Overhead zu reduzieren, aber dazu später mehr.
Grundsätzlich gilt: Je weniger dem Zufall überlassen wird, desto besser. Automatisierte Deployment-Werkzeuge wie Ansible oder Puppet sind nicht nur etwas für Großunternehmen. Auch ein Einzelkämpfer, der seine Instanz über Jahre betreibt, profitiert, wenn er die Konfiguration dokumentiert und versioniert. Der Grund ist einfach: Man vergisst nach sechs Monaten, warum man eine bestimmte Einstellung gewählt hat. Und der nächste Administrator – oder man selbst nach einem Systemausfall – muss die Logik nachvollziehen können, ohne stundenlang Rätselraten zu spielen.
Das Herzstück: PHP-FPM und der richtige Feinschliff
Kommen wir nun zum Kernstück der Nextcloud-Leistung: der PHP-Umgebung. Nextcloud ist in PHP geschrieben, und wie schnell die Software arbeitet, hängt maßgeblich von der Konfiguration des PHP-FPM-Pools ab. Viele Admins belassen es bei den Standardeinstellungen, und das ist oft ein Fehler. Einfache Parameter wie pm.max_children, pm.start_servers oder pm.max_requests haben einen großen Einfluss auf das Verhalten unter Last.
Die Angabe von pm.max_children bestimmt, wie viele parallele PHP-Prozesse zur Verfügung stehen. Ist die Zahl zu niedrig, warten Anfragen in der Warteschlange, und die Benutzeroberfläche fühlt sich träge an. Ist sie zu hoch, kann der Server mit zu vielen Prozessen und damit Speicherverbrauch überlastet werden. Ein guter Ansatz ist es, den verfügbaren Arbeitsspeicher durch den durchschnittlichen Speicherbedarf eines Prozesses zu teilen. Eine typische PHP-FPM-Worker-Einstellung für Nextcloud mit 16 GB RAM wäre etwa ein pm.max_children-Wert von 20 bis 30, abhängig von der durchschnittlichen Auslastung pro Request.
Dabei zeigt sich eine Eigenheit von Nextcloud: Die Software erzeugt für verschiedene Aufgaben unterschiedliche Arten von PHP-Prozessen. Es gibt die Prozesse für das Web-Frontend, Prozesse für die Synchronisation über WebDAV und Prozesse für die Hintergrundjobs. Alle werden über den gleichen Pool abgewickelt, was die Konfiguration knifflig macht. Eine Erhöhung der pm.max_requests ist ebenfalls empfehlenswert, da sie dafür sorgt, dass Prozesse nach einer bestimmten Anzahl von Anfragen neu gestartet werden – das räumt Speicherlecks und verbrauchte Variablen ab.
Ein beliebter Fehler ist es, das Timeout zu hoch anzusetzen. PHP hat von Haus aus ein max_execution_time von 30 Sekunden, was bei langen Uploads zu Problemen führen kann. Nextcloud empfiehlt, diesen Wert auf 3600 zu erhöhen, damit große Dateien hochgeladen und bearbeitet werden können. Aber Vorsicht: Eine zu großzügige Einstellung öffnet auch Tür und Tor für langlaufende, fehlerhafte Skripte, die den Server unnötig belasten. Ein guter Kompromiss ist ein Wert von 300 bis 600 Sekunden für den Webserver und ein separates Setting für die Console-Kommandos.
Nicht zu vergessen ist der Opcache. Dieser Mechanismus kompiliert PHP-Skripte in den Speicher und reduziert so die CPU-Last erheblich. Die Standardwerte des Opcache sind für WordPress und andere Systeme ausgelegt, für Nextcloud jedoch oft suboptimal. Insbesondere die Werte opcache.memory_consumption und opcache.max_accelerated_files sollten erhöht werden. Nextcloud selbst schlägt in der offiziellen Dokumentation vor, mindestens 128 MB für den Opcache einzuplanen und opcache.revalidate_freq auf 60 zu setzen, um bei Updates nicht in die Bredouille zu geraten. Ein weiterer wichtiger Parameter ist opcache.enable_cli, der für die Kommandozeilen-Skripte der Hintergrundjobs hilfreich ist.
Eine oft vernachlässigte Einstellung ist das Speicherlimit von PHP. Nextcloud benötigt je nach App und Komplexität der Anfragen schnell mehr als die standardmäßigen 128 MB. Gerade bei der Vorschau von Bildern oder der Verarbeitung von Office-Dokumenten wird viel Arbeitsspeicher benötigt. Daher sollte man memory_limit auf 512 MB oder sogar 1 GB setzen – gerade wenn man Collabora oder OnlyOffice in der Pipeline hat. Ein zu niedriger Wert führt zu kryptischen Fehlern und abgebrochenen Prozessen.
Redis und das Caching: Mehr als nur eine Nebensächlichkeit
Wer Nextcloud mit mehr als ein paar Benutzern betreibt, kommt an einem Redis-Server nicht vorbei. Redis dient als zentraler Cache für Transaktionsdateien, Sessions und Locking. Ohne Redis funktioniert Nextcloud zwar grundsätzlich, aber es kommt schnell zu Engpässen bei der Speicherung von Sessions und beim Datei-Locking, das mehrere Benutzer am selben Dokument arbeiten lassen möchte. Vor allem bei synchronisierten Clients sorgt Redis für eine deutliche Entlastung, da die Clients ihre Abfragen nicht sofort mit einem Datenbankzugriff beantworten müssen.
Die Einrichtung von Redis ist in den meisten Fällen unkompliziert. Man installiert das Paket, passt die config.php von Nextcloud an und fügt die entsprechenden Einstellungen hinzu. Dabei sollte man sich entscheiden, ob Redis als UNIX-Socket oder über TCP angesprochen werden soll. Ein UNIX-Socket ist meist schneller, da er den Netzwerk-Overhead vermeidet. Jedoch ist die Konfiguration etwas fummeliger, da der Webserver die Rechte auf den Socket besitzen muss.
Ein interessanter Aspekt ist die Verwendung von Redis für das Datei-Locking. Nextcloud bietet verschiedene Mechanismen, das Locking zu implementieren – dabei werden Dateien vorübergehend für andere Benutzer gesperrt, wenn sie gerade in einem Editor geöffnet sind. Mit der memcache.locking-Einstellung kann man Nextcloud auf Redis verweisen, was im Vergleich zur Standard-Datenbank-Konfiguration eine deutlich bessere Performance liefert. Das ist besonders dann wichtig, wenn man Collabora oder OnlyOffice integriert, da diese Echtzeit-Bearbeitung auf dem Server sehr viel häufiger Zugriffe erzeugt als ein simples Upload/Download-Szenario.
Zusätzlich sollte man Redis auch für den Query-Cache der Datenbank verwenden. Dazu trägt man in der config.php den Eintrag 'memcache.distributed' => '\Redis' ein. Das führt dazu, dass wiederkehrende Datenbankabfragen nicht mehr jedes Mal komplett durchlaufen, sondern aus dem Cache beantwortet werden. Die Effizienzsteigerung ist messbar – gerade bei einer größeren Gruppenbibliothek oder bei vielen Freigaben. Allerdings gilt: Redis ist kein Ersatz für eine schlechte Datenbank-Indizierung. Wer massive Performance-Probleme hat, sollte zuerst die Datenbank analysieren, bevor er die Schuld auf das Caching schiebt.
Ein weiterer, oft übersehener Vorteil von Redis: Es kann als Session-Handler verwendet werden. Dadurch werden PHP-Sessions nicht mehr in Dateien gespeichert, sondern im Arbeitsspeicher gehalten. Das reduziert die I/O-Last auf dem Dateisystem und beschleunigt den Login-Vorgang und die Benutzer-Authentifizierung. Vor allem bei vielen gleichzeitigen WebDAV-Verbindungen, die ständig Sessions aufbauen, bemerkt man den Unterschied deutlich.
Es lohnt sich, die Redis-Konfiguration regelmäßig zu überwachen – nicht nur in Bezug auf die Speichernutzung, sondern auch auf die Operationen pro Sekunde. Ein gut konfigurierter Redis-Server ist unauffällig und stabil. Wenn er jedoch falsch konfiguriert ist – etwa mit zu wenig Speicher –, führt dies zu massiven Störungen. Typisches Symptom: Die Benutzeroberfläche lädt, aber Anmeldungen schlagen erst nach einer Verzögerung fehl. Ein Blick in das Redis-Log hilft, solche Symptome von Datenbankproblemen zu unterscheiden.
Hintergrundjobs: Cron läuft, aber richtig?
Nextcloud erledigt viele Aufgaben im Hintergrund: das Erzeugen von Vorschaubildern, das Scannen von Dateien, das Versenden von Benachrichtigungen und das Verwalten von Freigaben. Für diese Aufgaben gibt es drei mögliche Modi: AJAX, Webcron und Cron (Unix-Kommando). Der AJAX-Modus wird standardmäßig verwendet, ist aber für Produktivumgebungen ungeeignet, da die Aufgaben nur ausgelöst werden, wenn ein Benutzer die Weboberfläche besucht. Bei hoher Last führt das zu unkontrollierten Spitzen, da parallel zur normalen Server-Antwort auch die Hintergrundjobs laufen.
Webcron ist eine leichtere Alternative, bei der ein externer Dienst regelmäßig eine URL aufruft. Sie erspart den Ajax-Overhead, hat aber ebenfalls das Problem, dass die Jobs nicht kontinuierlich abgearbeitet werden. Für ernsthafte Installationen kommt nur der Cron-Modus in Frage. Hierbei wird über einen systemd-Timer oder einen klassischen Cron-Job das Skript cron.php regelmäßig – üblicherweise alle 5 Minuten – ausgeführt. Das versetzt Nextcloud in die Lage, Aufgaben zu queueen und periodisch zu verarbeiten.
Ein häufiger Fehler ist es, den Cron-Job einfach zu aktivieren und dann zu vergessen, dass die PHP-CLI-Konfiguration von der Webserver-Konfiguration abweicht. Wenn das PHP-Speicherlimit oder die Timeouts für die Kommandozeile zu niedrig sind, schlagen Hintergrundjobs unbemerkt fehl. Das ist besonders tückisch, weil die Fehler nicht sofort sichtbar sind, sondern sich erst nach einiger Zeit ansammeln – etwa wenn keine Vorschauen erzeugt werden oder die Aktivitäten-Feeds leer bleiben. Wer die Konfiguration anpasst, sollte also immer die CLI-PHP-INI nicht vergessen.
Ein weiterer Punkt ist die Lastverteilung. Bei großen Instanzen macht es Sinn, die Hintergrundjobs auf eine separate Maschine auszulagern, insbesondere wenn viele Vorschauen für Bilder oder Videos erzeugt werden. Dazu trägt man in der config.php einen eigenen Cron-Host ein und lässt die Hauptinstanz nur für die Verarbeitung von Anfragen zuständig sein. Das ist zwar eine fortgeschrittene Konfiguration, aber bei 200 Benutzern und viel Mediennutzung spürt man die Entlastung sofort.
Es ist auch wichtig, das Verhalten von cron.php zu verstehen. Das Skript ruft für jede geplante Aufgabe einen PHP-Prozess auf. Wenn viele Aufgaben anstehen, kann dieser Prozess länger laufen als üblich. Deshalb sollte man das Zeitlimit für den Cron-Job nicht zu knapp setzen. Andernfalls wird der Prozess abgebrochen, noch bevor er die Hälfte der Aufgaben verarbeitet hat. Die Kunst ist es, die richtige Balance zwischen Häufigkeit und Umfang zu finden. Ein 5-Minuten-Intervall ist ein guter Ausgangspunkt; wenn die Zahl der anstehenden Aufgaben stetig wächst, sollte man das Intervall eher auf 2 Minuten reduzieren, als die Systemlast zu erhöhen.
Dateisystem und Storage: Was unter der Haube passiert
Nextcloud unterstützt verschiedene Dateisysteme und Storage-Backends – von lokalen Ordnern über SMB- und NFS-Mounts bis hin zu S3-Objektspeichern. Jede Option hat ihre Eigenheiten, und nicht jede ist für den produktiven Einsatz mit hohen Anforderungen geeignet. Ein lokales Dateisystem ist immer noch die beste Wahl, wenn es um Geschwindigkeit geht, vorausgesetzt, die Hardware stimmt. Aber mit wachsender Datenmenge wird das Dateisystem schnell zum Flaschenhals, wenn die Ordnerstruktur unübersichtlich wird.
Nextcloud speichert die Dateien nicht im klassischen Ordner-layout ab. Stattdessen werden die Dateien in einer eigenen Struktur im data-Verzeichnis abgelegt, in der jeder Benutzer einen Ordner hat. Diese Struktur sieht auf den ersten Blick chaotisch aus, ist aber gewollt, weil sie Kollisionen vermeidet und die Zuordnung erleichtert. Allerdings kann sie dazu führen, dass die Verwaltung von sehr vielen Dateien ineffizient wird, wenn das Dateisystem nicht dafür ausgelegt ist. Ein Ext4-Dateisystem kommt bei Millionen von kleinen Dateien an seine Grenzen, während XFS oder Btrfs in solchen Szenarien oft besser skalieren.
Interessant ist auch die Option, das Dateisystem von der Datenbank zu trennen und auf einen Objektspeicher auszuweichen. S3-kompatible Speicher wie MinIO oder Ceph sind gerade im Unternehmensumfeld beliebt, weil sie fast unbegrenzt skalieren und sich leicht in die Nextcloud-Architektur integrieren lassen. Man sollte jedoch wissen: Objektspeicher sind nicht unbedingt schneller als eine lokale NVMe-SSD. Sie glänzen eher durch ihre Flexibilität und Ausfallsicherheit. Für eine kleine Instanz mit einer Handvoll Benutzern ist ein S3-Setup überdimensioniert und führt oft zu höheren Latenzen.
Was die Performance betrifft, sollte man außerdem die Verwendung des PHP-Dateisystem-Caches prüfen. Nextcloud hat die Möglichkeit, die Ergebnisse von Dateisystemoperationen für ein paar Sekunden zu cachen. Das reduziert die Last der stat()-Aufrufe, die bei jeder Synchronisierung aufgerufen werden. Der Cache kann über die config.php-Einstellung 'filecache' konfiguriert werden. In Kombination mit Redis bringt das einen spürbaren Schub – vor allem bei Desktop-Clients, die häufig den Ordner-Status abfragen.
Ein häufig unterschätzter Aspekt sind die Berechtigungen und die Benutzerverwaltung auf dem Dateisystem. Nextcloud kann die Benutzer über LDAP oder SSO anbinden. Wenn diese externen Systeme langsam reagieren, wirkt sich das unmittelbar auf die Dateisystemperformance aus, da Nextcloud bei jedem Zugriff prüfen muss, ob der Benutzer überhaupt berechtigt ist. Ein LDAP-Timeout von ein paar Sekunden kann ganze Uploads lahmlegen. Deshalb ist es ratsam, die LDAP-Anbindung mit Puffern und Caches zu optimieren – oder zumindest die Timeouts aggressiv zu setzen.
Webserver: Nginx oder Apache – die ewige Frage
Die Wahl des Webservers ist eine Grundsatzentscheidung. Die meisten Nextcloud-Installationen laufen auf Apache, und das aus gutem Grund: Die Dokumentation von Nextcloud ist traditionell auf Apache zugeschnitten, und viele App-Entwickler testen nur mit Apache. Doch in Sachen Performance hat Nginx in vielen Szenarien die Nase vorn, weil es unter Last weniger Speicher verbraucht und eine ereignisgesteuerte Architektur nutzt. Das bedeutet nicht, dass Apache grundsätzlich schlechter ist – aber es erfordert mehr Feintuning, um mit Nginx mitzuhalten.
Wer Apache einsetzt, sollte zumindest auf die MPM-Events- und nicht auf die klassische Prefork-Variante setzen. Prefork ist robust, aber ein Speicherfresser, weil es für jede Verbindung einen eigenen Prozess startet. Mit dem Event-MPM und PHP-FPM erreicht man ein deutlich besseres Verhältnis zwischen Last und Ressourcenverbrauch. Dazu kommen die üblichen Anpassungen wie das Aktivieren von HTTP/2 und die Komprimierung von Inhalten. Nginx bringt diese Funktionen bereits aus dem Effeff mit, während man sie bei Apache erst konfigurieren muss.
Ein Nginx-Setup für Nextcloud ist nicht kompliziert, aber es gibt einige Fallstricke. Insbesondere die korrekte Konfiguration von client_max_body_size ist entscheidend: Wenn der Wert zu niedrig ist, schlagen Uploads großer Dateien mit einem 413-Fehler fehl. Viele Admins setzen diesen Wert einfach auf 0 (unbegrenzt), was zwar funktioniert, aber nicht gerade elegant ist. Die bessere Lösung ist es, den Wert großzügig, aber realistisch zu wählen – etwa 10 oder 20 GB, je nach erwarteter Dateigröße. Ähnlich verhält es sich mit den Timeouts. Nginx gibt die Verbindung bei einem zu niedrigen proxy_read_timeout auf, während Nextcloud noch die Daten verarbeitet. Das führt zu abgebrochenen Downloads und sorgt beim Benutzer für Verwirrung.
Ein nicht zu unterschätzender Vorteil von Nginx ist die gute Integration mit PHP-FPM. Man kann für verschiedene Pfade eigene PHP-Pools definieren, um die Last besser zu verteilen. Zum Beispiel könnte man den WebDAV-Endpunkt mit einem eigenen, höher priorisierten Pool versorgen, damit synchronisierende Clients nicht von normalen Web-Requests ausgebremst werden. Das ist fortgeschrittenes Tuning, aber mit ein wenig Hintergrundwissen gut umsetzbar.
Schlussendlich ist es eine Frage der Erfahrung und der Vorlieben. Man kann auch mit Apache eine sehr performante Nextcloud-Instanz betreiben – wenn man sich die Mühe macht, die Konfiguration zu verstehen. Andererseits neige ich persönlich zu Nginx, weil die Konfiguration transparenter wirkt und man weniger Standard-Werte umschiffen muss. Aber wie so oft gilt: Das Werkzeug ist weniger wichtig als das Know-how des Administrators.
Zusätzliche Apps und Services: Collabora, OnlyOffice und Co
Nextcloud ist mehr als nur ein Dateispeicher. Mit App-Erweiterungen kann man Dokumente bearbeiten, Videokonferenzen abhalten oder E-Mails verwalten – direkt auf dem eigenen Server. Diese Zusatzfunktionen sind einerseits ein Segen, andererseits eine enorme Belastung für die Server-Ressourcen. Vor allem die Integration von Collabora Online oder OnlyOffice kann die Performance der gesamten Instanz beeinflussen.
Collabora Online ist ein Dienst, der auf einem eigenen Server läuft und normalerweise über das integrierte CODE (Collabora Online Development Edition) Paket installiert wird. Wenn dieser Dienst auf der gleichen Maschine läuft wie die Nextcloud-Instanz, braucht man deutlich mehr RAM und CPU-Leistung. Ein typisches Szenario: Ein Benutzer öffnet ein Tabellen-Dokument, und sofort werden mehrere Prozesse gestartet, um die Bearbeitung zu ermöglichen. Bei zehn gleichzeitigen Nutzern kann das den Server spürbar fordern. Deshalb ist es ratsam, Collabora auf eine separate Maschine oder zumindest in einen eigenen Container zu legen, der Ressourcen-Limits hat.
OnlyOffice verhält sich ähnlich. Es benötigt Node.js- und Postgres-Komponenten, was die Komplexität erhöht. Die Konfiguration ist nicht immer intuitiv, und man muss darauf achten, dass die Websocket-Verbindungen nicht durch Firewalls oder Reverse-Proxys blockiert werden. Nicht zuletzt deshalb ist meine Empfehlung für kleinere Installationen, auf die klassische Nextcloud-Text- und Tabellenverwaltung zu setzen, die auf einem einfachen Texteditor basiert. Diese funktioniert ohne Zusatzdienste und ist erstaunlich effektiv, auch wenn sie nicht den Komfort von Echtzeit-Kollaboration bietet.
Doch zurück zu den Apps: Es gibt eine Vielzahl von Add-ons, die die Server-Leistung beeinflussen können. Die Vorschau-Generierung für Bilder und Videos ist ein berüchtigter Ressourcenfresser. Wer standardmäßig alle Vorschau-Größen für alle Medien generieren lässt, braucht viel CPU und I/O. Eine clevere Konfiguration reduziert die Anzahl der Vorschau-Größen auf das Nötigste oder erzeugt sie nur on demand. Auch die Aktivitäten-App kann bei großen Instanzen Datenbanktabellen anschwellen lassen, was zu langsamen Abfragen führt. Das regelmäßige Bereinigen der Aktivitäten-Datenbank oder das Deaktivieren unnötiger Aktivitätstypen kann Wunder bewirken.
Ein interessanter Aspekt ist die Verwendung von Nextcloud als Ersatz für Teams, Slack und ähnliche Dienste. Die Talk-App bringt Echtzeit-Kommunikation, Video-Konferenzen und Bildschirmübertragungen auf den Server. Das klingt verlockend, aber die damit verbundene Last ist enorm. Jede Video-Konferenz erzeugt einen Strom von UDP- und TCP-Paketen, die den Server nicht nur durch den Datenverkehr fordern, sondern auch durch die Signalverarbeitung. Wer Talk produktiv nutzen möchte, muss den Server nicht nur für die Dateiablage, sondern auch als Streaming-Infrastruktur planen. Das ist ein anderes Kaliber als das Hosten von Dateien.
Desktop-Clients und Synchronisation: Die andere Seite der Medaille
Die Leistung einer Nextcloud-Instanz hängt nicht nur vom Server ab. Auch der Client auf den Rechnern der Benutzer spielt eine wichtige Rolle. Viele Administratoren unterschätzen, wie stark die Desktop-Clients den Server belasten können – insbesondere dann, wenn sie standardmäßig die Ordnerstruktur dauerhaft überwachen. Der Nextcloud-Client muss bei jeder Änderung eine Abfrage an den Server schicken und die lokale Datenbank abgleichen. Das ist nicht besonders effizient, wenn es sich um einen Ordner mit Tausenden von Dateien handelt.
Hinzu kommt das Verhalten der Clients bei der Bearbeitung von Konflikten. Wenn zwei Benutzer gleichzeitig dieselbe Datei ändern, erzeugt Nextcloud eine Konfliktkopie, die sowohl auf dem Server als auch auf dem Client gespeichert wird. Das führt zu zusätzlichen Synchronisationsläufen und kann bei schwachem Netzwerk zu einer Endlosschleife werden. Ein guter Administrationshinweis ist daher, die Benutzer zu schulen und die Sperrfunktion (File Locking) zu aktivieren. Das verhindert zwar nicht alle Konflikte, reduziert sie aber erheblich.
Für die Synchronisation von sehr großen Verzeichnisbäumen gibt es eine Einstellung, die die Vorschau-Generierung unterdrückt. Standardmäßig erzeugt der Nextcloud-Client beim Synchronisieren von Bildern Vorschaubilder, die auf dem Server gespeichert werden. Das ist nützlich für die Weboberfläche, kostet aber unnötig viel Serverleistung, wenn Hunderte von Bildern auf einmal hinzugefügt werden. Unterdrückt man die Vorab-Generierung oder stellt sie auf einen späteren Zeitpunkt ein, beschleunigt das die Synchronisation spürbar.
Ein weiterer Client-bedingter Performance-Faktor ist die Anzahl der gleichzeitigen Verbindungen. Der Nextcloud-Client öffnet für jede Datei eine eigene HTTP-Verbindung, manchmal sogar mehrere parallel. Wenn der Server diese Verbindungen nicht schnell beantwortet, startet der Client einen Backoff – und die Benutzer sehen eine träge Synchronisation. Hierbei kann eine Optimierung des Webservers und des PHP-FPM Wunder wirken. Auch die Verwendung von HTTP/2 hilft, da der Client dadurch mehrere Anfragen über eine einzige Verbindung abwickeln kann, anstatt ständig neue Verbindungen aufzubauen.
Es ist zudem ratsam, die Client-Versionen im Auge zu behalten. Ältere Clients nutzen oft ineffiziente Protokolle und erzeugen mehr Last als nötig. Nextcloud verbessert die Synchronisationsalgorithmen stetig, und ein Update der Desktop-Clients kann daher auch die Server-Performance merkbar entlasten. Nicht immer sitzt das Problem also auf der Server-Seite – manchmal ist der Flaschenhals schlicht in veralteten Client-Versionen zu suchen. Dieser Punkt wird häufig übersehen, weil die Aufmerksamkeit des Administrators natürlich auf dem Server liegt. Doch die Synchronisations-Client-Erfahrung ist das, was der Endanwender täglich spürt.
Monitoring und logische Abläufe: Wer nicht misst, bleibt blind
Performance-Tuning ist kein einmaliges Ereignis, sondern ein fortlaufender Prozess. Die Anforderungen an eine Nextcloud-Instanz ändern sich, die Anzahl der Benutzer wächst, die Dateimengen nehmen zu, neue Apps kommen dazu. Deshalb ist ein kontinuierliches Monitoring unabdingbar. Ohne Messwerte tappt man im Dunkeln und verlässt sich auf Bauchgefühl – und das ist bei komplexer Software selten eine gute Grundlage.
Die wichtigsten Kennzahlen: durchschnittliche Antwortzeit der Webseite, Anzahl der gleichzeitigen PHP-FPM-Prozesse, Speichernutzung, Datenbankabfragen pro Sekunde, Latenz der Storage-I/Os und die Warteschlangenlänge im Redis. Wenn man diese Werte über einen gewissen Zeitraum erfasst, kann man enge Muster erkennen. Beispielsweise zeigt sich oft, dass die Serverlast zwischen 9 und 10 Uhr massiv ansteigt, wenn die Mitarbeiter am Morgen ihre Rechner hochfahren und die Clients beginnen, Änderungen zu synchronisieren. Mit diesem Wissen kann man die Hintergrundjobs umplanen oder die PHP-FPM-Parameter anpassen.
Dabei zeigt sich auch, dass manche Apps in Nextcloud wahre Performance-Sünder sind. Die externe Storage-Integration etwa kann beim Abruf von Metadaten zu langen Wartezeiten führen, wenn die externen Quellen langsam sind. Ein Monitoring-System, das die Reaktionszeiten einzelner Apps misst, hilft hier weiter. Nextcloud selbst stellt über die OCS-API oder die occ-Kommandos einige interne Statistiken bereit, aber für eine echte Übersicht braucht es ein selbst gestricktes Monitoring-Setup.
Ich empfehle, die Metriken nicht nur aufzuzeichnen, sondern auch zu alarmieren. Ein einfacher Check, der prüft, ob die Webseite in unter drei Sekunden lädt, ist ein guter Anfang. Besser ist es, Schwellenwerte für die durchschnittliche Antwortzeit pro Endpunkt zu definieren und eine Benachrichtigung auszulösen, wenn diese überschritten werden. So bleiben kritische Zustände nicht unbemerkt, bis die Anwender sich beschweren.
Für die Analyse von Einzelproblemen ist ein Blick in die Logs unerlässlich. Sowohl der Nextcloud-eigene Log (Neben der Datenbank) als auch die Logs von PHP-FPM, Nginx oder Apache und Datenbank sollten regelmäßig geprüft werden. Die Schwierigkeit besteht darin, die Flut an Log-Einträgen zu filtern. Ein Tool wie Grafana Loki oder ein einfaches ELK-Setup kann helfen, Log-Muster zu erkennen und zu visualisieren. Das ist zunächst ein gewisser Aufwand, zahlt sich aber schnell aus, wenn man einmal einen schwierigen Performance-Bug jagt, der sich nur durch gezielte Log-Analyse finden lässt.
Und dann ist da noch die Frage der Datenbankpflege. Eine Nextcloud-Datenbank neigt im Laufe der Zeit zu Fragmentierung – insbesondere bei vielen Lösch- und Schreibvorgängen, wie sie bei aktiver Synchronisation entstehen. Ein regelmäßiger Vakuum- oder Optimier-Lauf für PostgreSQL oder MySQL hält die Abfragen schnell. Ich rate dazu, diese Wartung in den wöchentlichen Wartungsplan aufzunehmen und sie in verkehrsarmen Zeiten durchzuführen. Das kann man über einen Cron-Job erledigen, aber man sollte die Auswirkungen auf die Systemlast beobachten.
Der Blick aufs Ganze: Nextcloud ist keine Fire-and-Forget-Software
Nach all den Detailbetrachtungen bleibt ein Fazit, das man so nicht in jeder Doku findet: Nextcloud ist ein mächtiges Werkzeug, das aber seinen Preis in Form von Wartungsaufwand und technischem Know-how fordert. Wer die Software ernsthaft im Unternehmen einsetzen will, muss bereit sein, sich intensiv mit den Grundlagen zu beschäftigen. Es gibt keine „magische“ Einstellung, die alle Probleme löst. Die Performance einer Nextcloud-Instanz ist das Ergebnis einer Kette von Entscheidungen: vom zugrunde liegenden Betriebssystem über die Hardware bis zur Konfiguration der einzelnen Dienste.
Ein interessanter Aspekt in diesem Zusammenhang ist der Umgang mit Updates. Nextcloud bringt regelmäßig neue Versionen heraus, die nicht nur neue Funktionen, sondern auch Performance-Verbesserungen enthalten. Wer allerdings blindlings aktualisiert, läuft Gefahr, dass spezifische Anpassungen an der Konfiguration überschrieben oder ungültig werden. Deshalb gehört zu einem soliden Tuning auch eine durchdachte Update-Strategie. Dazu gehört, dass man die Release-Notes liest, in einer Testumgebung aktualisiert und erst nach erfolgreicher Prüfung den Produktivbetrieb übernimmt.
Die Community rund um Nextcloud ist lebendig und hilfsbereit – das ist ein Glücksfall. In Foren und Mastodon-Kanälen tauschen sich Admins über die unterschiedlichsten Probleme aus, und nicht selten findet man Lösungen, die in der offiziellen Doku fehlen. Trotzdem sollte man nicht jedem Blog-Post vertrauen, der schnelle Performance-Tipps verspricht. Manche Vorschläge, wie das Disablen von Logging oder das Overriden von Timeouts, können auf den ersten Blick hilfreich sein, erzeugen aber auf lange Sicht neue Probleme. Viele „Tuning-Tipps“ sind im Grunde nichts anderes als das Kaschieren von zugrunde liegenden Architekturfehlern.
Wer eine Nextcloud-Instanz mit Leidenschaft betreibt, wird irgendwann eine gewisse Intuition entwickeln. Man spürt, wann das System unter Druck steht, ohne vorher auf das Monitoring schauen zu müssen – und man weiß, welche Stellschrauben man zuerst anfassen sollte, wenn die Symptome da sind. Das ist keine Kunst, sondern das Ergebnis von Erfahrung und der Bereitschaft, sich auf die Komplexität einzulassen. Dazu gehört auch, sich einzugestehen, dass nicht jedes Problem lösbar ist – zumindest nicht ohne den Einsatz von deutlich mehr Ressourcen. Gelegentlich ist die schlichte Wahrheit: Die Maschine ist schlicht zu klein, die Dateistruktur zu groß, die Anforderungen zu hoch.
Letztlich ist Nextcloud ein gutes Beispiel für die Reifung von Open-Source-Software. Die Endnutzer-Perspektive ist heute mit Dropbox und Google Drive vergleichbar – oft sogar besser, wenn es um Datenschutz und Souveränität geht. Doch das Versprechen von Selbstbestimmung ist untrennbar mit der Verantwortung des Betreibers verbunden. Der komfortable Weg, sich bei einem kommerziellen Anbieter anzulehnen, bleibt verlockend. Wer jedoch den Schritt wagt und die Mühen der eigenen Infrastruktur auf sich nimmt, wird letztlich mit einer Kontrolle belohnt, die kein externer Dienst bieten kann. Und mit der Performance, die man selbst erarbeitet hat, ist man automatisch besser vorbereitet – auf neue Anwender, neue Features und die digitalen Herausforderungen von morgen.
„`