Nextcloud Tuning: Mehr Tempo für die private Cloud – ein Werkstattbericht
Wer Nextcloud betreibt, kennt das Phänomen: Nach der frischen Installation läuft alles butterweich. Dateien synchronisieren im Nu, die Oberfläche reagiert flott, die Suche fördert Treffer zutage, bevor man den Suchbegriff zu Ende getippt hat. Doch mit der Zeit – nach ein paar Dutzend Benutzern, etlichen tausend Dateien und vielleicht dem einen oder anderen Update – wird das System zäher. Der Browser hängt beim Laden der Ordnerstruktur, der Sync pausiert verdächtig lange, und die Nextcloud-Richdocuments brauchen gefühlt eine Ewigkeit, bis sie geladen sind. Was tun? Das klassische Tuning.
Doch Tuning ist nicht gleich Tuning. Manche greifen zu pauschalen Rezepten aus Foren: „Erhöhe einfach die PHP-Limits“ oder „Setze Redis ein und alles wird gut“. Das ist nicht falsch, aber selten hinreichend. Ein professionelles Nextcloud-Tuning beginnt mit einer Bestandsaufnahme. Wo drückt der Schuh? Liegt es an der Datenbank, am Storage, am Webserver oder tatsächlich an der PHP-Konfiguration? Oder – ein leidiges Thema – an den Apps, die sich wie Karnickel vermehren und selbst dann Ressourcen fressen, wenn sie gar nicht gebraucht werden? Ein interessanter Aspekt ist, dass viele Administratoren die Ursache ihres Problems im falschen Bereich suchen. Sie tunen die Datenbank, aber der Engpass sitzt im Dateisystem. Oder sie optimieren den Cache, aber das eigentliche Problem ist ein ineffizienter Cronjob. Es lohnt sich, systematisch vorzugehen.
Das Fundament: PHP, Webserver und die richtige Prozessverwaltung
Beginnen wir am Anfang: Nextcloud ist eine PHP-Anwendung. Das klingt banal, aber genau hier liegt einer der häufigsten Flaschenhälse. Wer Apache mit mod_php betreibt, lebt gefährlich – zumindest aus Performance-Sicht. mod_php bindet den PHP-Interpreter direkt in den Webserver ein. Bei jeder Anfrage wird ein ganzer PHP-Prozess gestartet, der nach der Abarbeitung wieder verfällt. Das ist ressourcenintensiv und skaliert schlecht. Besser ist der Einsatz von PHP-FPM (FastCGI Process Manager) in Kombination mit Nginx oder Apache im Event-MPM-Modus. PHP-FPM hält einen Pool von PHP-Prozessen vor, die wiederverwendet werden. Das reduziert den Overhead erheblich. Und es erlaubt eine granulare Steuerung der Prozessanzahl, abhängig von Arbeitsspeicher und Last.
Die Konfiguration des PHP-FPM-Pools will wohlüberlegt sein. Die Parameter pm.max_children, pm.start_servers, pm.min_spare_servers und pm.max_spare_servers bestimmen, wie viele PHP-Prozesse gleichzeitig laufen können. Ein grober Richtwert: Jeder Nextcloud-PHP-Prozess belegt etwa 30 bis 80 MByte RAM – je nach installierten Apps und gleichzeitig geladenen Dateien. Bei einem Server mit 16 GByte RAM sollte man also nicht mehr als 150 bis 200 Prozesse zulassen, sonst kollabiert der Speicher. Doch Vorsicht: Zu wenige Prozesse führen zu Wartezeiten, sobald mehrere Benutzer gleichzeitig zugreifen. Hier hilft Monitoring: pm.status_path in PHP-FPM liefert live Daten über die Auslastung. Ein Blick auf die Werte über ein Tool wie php-fpm-exporter oder einfach via curl auf den Status-Endpunkt – das sollte man regelmäßig tun, nicht nur beim Tuning.
Nicht zuletzt spielt auch die PHP-Version eine Rolle. Nextcloud empfiehlt aktuell PHP 8.1 oder 8.2 – und das aus gutem Grund: Die JIT-Engine in PHP 8.0 und neuer beschleunigt viele Operationen spürbar. Aber man sollte nicht blind updaten. Zunächst prüfen, ob alle Apps kompatibel sind. Vor einigen Monaten gab es etwa Probleme mit bestimmten Versionen der Preview-Generator-App unter PHP 8.2. Solche Stolpersteine lassen sich durch einen Test in einer Staging-Umgebung umgehen. Auch der OPcache sollte richtig konfiguriert sein: opcache.enable=1, opcache.memory_consumption=256, opcache.max_accelerated_files=10000 – das sind Werte, die für die meisten Nextcloud-Installationen taugen. Zu klein dimensionierter OPcache führt dazu, dass Skripte immer wieder neu kompiliert werden, was die CPU unnötig belastet.
Der stille Helfer: Caching mit Redis und APCu
Nextcloud nutzt standardmäßig eine Datenbank, um Metadaten, Sessions und Cache-Einträge zu verwalten. Das funktioniert, aber unter Last wird die Datenbank schnell zum Flaschenhals. Die Abhilfe heißt: In-Memory-Caching, und zwar mit Redis. APCu (Alternative PHP Cache) kann ebenfalls verwendet werden, ist aber nur für den lokalen Cache auf einem einzelnen Server geeignet. Redis hingegen ist als zentraler Cache für Cluster-Installationen die erste Wahl. Es speichert Datei-Metadaten, Sperren (Locks) und Sessions extrem schnell im Arbeitsspeicher, anstatt jedes Mal die Datenbank zu belasten. Die Einrichtung ist vergleichsweise simpel: Redis installieren, die entsprechende PHP-Extension (redis) nachladen und in der config.php die Parameter 'memcache.distributed' => '\Redis', 'memcache.local' => '\APCu' setzen. Aber Achtung: Es gibt Fallstricke. Redis sollte nicht default-mäßig mit save "" betrieben werden, sonst geht der Cache bei einem Neustart verloren. Persistente Konfiguration mit save 900 1 oder ähnlich ist ratsam, auch wenn der Cache bei einer Instabilität wieder aufgebaut werden muss. Ein interessanter Aspekt: Man kann Redis auch für das Locking verwenden ('filelocking.enabled' => true in Kombination mit 'memcache.locking' => '\Redis'). Das verhindert gleichzeitige Schreibzugriffe auf dieselbe Datei – ein typisches Problem bei vielen Sync-Vorgängen. Die Umstellung auf Redis-basiertes Locking hat bei einer mittelgroßen Installation, die ich betreut habe, die Fehlerrate bei gleichzeitigen Uploads von mehreren Benutzern drastisch reduziert.
APCu allein für den lokalen Cache zu benutzen ist übrigens auch eine Option, aber dann entfällt der Vorteil des verteilten Caches. In einer Umgebung mit mehreren Nextcloud-Servern (etwa hinter einem Load Balancer) führt lokales Caching zu Inkonsistenzen: Server A hat eine neue Datei im Cache, Server B nicht. Redis löst das elegant, weil alle Server auf denselben Cache-Pool zugreifen. Wer nur einen einzigen Server betreibt, kann auch auf Redis verzichten und auf APCu setzen, aber die Performance-Gewinne durch Redis sind selbst dann meist spürbar, weil die Datenbank entlastet wird.
Datenbank-Tuning: Der oft unterschätzte Hebel
Die mit Abstand häufigste Ursache für lahme Nextcloud-Instanzen ist eine suboptimal konfigurierte oder schlichtweg falsch gewählte Datenbank. Nextcloud unterstützt MySQL/MariaDB, PostgreSQL und seit einiger Zeit auch SQLite (nur für Test- oder Einzelbenutzer-Installationen). In der Praxis dominieren MariaDB und MySQL, gefolgt von PostgreSQL. Und hier zeigt sich ein interessantes Phänomen: Viele Administratoren installieren Nextcloud mit den Standard-Datenbank-Werten und wundern sich dann, warum die Performance nachlässt. Standard-MySQL-Konfigurationen sind oft auf kleine Arbeitsspeicher oder ältere Hardware ausgelegt. Ein typischer Flaschenhals ist der InnoDB-Pufferpool (innodb_buffer_pool_size). Dieser speichert Tabellen und Indizes im Arbeitsspeicher. Für eine Nextcloud-Instanz mit einigen Tausend Dateien sollten mindestens 1 bis 2 GByte eingeplant werden. Bei größeren Installationen (ab 100.000 Dateien) sind 4 oder 8 GByte keine Seltenheit. Ein Richtwert: Der Pufferpool sollte etwa 70 bis 80 Prozent des gesamten Datenbankvolumens ausmachen – gemessen an der Größe der Nextcloud-Tabellen (oc_filecache, oc_storages, etc.). Ein Blick auf SHOW TABLE STATUS gibt Auskunft über die aktuellen Größen.
Weitere Parameter: innodb_log_file_size und innodb_flush_log_at_trx_commit. Letzterer bestimmt, wie oft die Transaktionslogs auf die Festplatte geschrieben werden. Standardwert 1 ist sicher (jede Transaktion wird sofort geflusht), aber langsam. Für eine Nextcloud, die viele kleine Schreiboperationen ausführt (etwa bei Metadaten-Updates), kann man auf 2 setzen, wenn man Datenverlust im Falle eines Absturzes in Kauf nimmt (einmal pro Sekunde). In der Praxis ist das Risiko gering, weil die Logs regelmäßig gesichert werden. Auch die query_cache_type sollte deaktiviert sein (standardmäßig in MySQL 8 und MariaDB 10.5+ ohnehin), da der Query Cache nur bei reinen Lese-Last-Profilen hilft und bei Schreiboperationen sogar schadet. Nextcloud hat eine Mischung aus Lese- und Schreibzugriffen. Also besser ausschalten.
PostgreSQL steht im Ruf, bei komplexen Abfragen performanter zu sein als MySQL/MariaDB. Besonders bei der Nextcloud-Suche (Fulltext-Suche) kann PostgreSQL punkten, weil es nativen Volltext-Support bietet. Allerdings erfordert die Umstellung auf PostgreSQL (oder auch die Migration) etwas Aufwand. Wer neu aufsetzt, sollte zumindest eine Testinstallation mit PostgreSQL machen und dann vergleichen. In meinen Tests hat PostgreSQL bei Instanzen mit vielen Dateien (über einer Million) und vielen parallelen Abfragen besser abgeschnitten. MySQL/MariaDB muss dann oft mit innodb_adaptive_hash_index und innodb_flush_neighbors nachgeholfen werden. Ein Satz, den man sich merken sollte: Die Datenbank ist das Herzstück – stopfe sie nicht mit Standardwerten voll.
Storage: Der langsame Riese im Keller
Nextcloud speichert Dateien im Dateisystem. Das klingt unspektakulär, aber die Wahl des Storage-Backends hat massiven Einfluss auf die Performance. Lokale SSDs sind natürlich am schnellsten, aber nicht immer möglich. Viele Setups verwenden NFS, NAS oder sogar Object Storage wie S3 (etwa via MinIO oder AWS S3). Gerade NFS ist ein klassischer Performance-Killer, wenn es nicht richtig konfiguriert ist. NFS-Version 4.1 oder 4.2 mit actimeo (Attribut-Cache-Timeout) angepasst auf 60 oder 120 Sekunden – das entlastet den NFS-Server erheblich. Nextcloud selbst macht viele stat-Aufrufe (z. B. um Dateigrößen zu prüfen). Jeder dieser Aufrufe geht bei NFS über das Netzwerk. Mit einem zu kleinen actimeo explodiert die Latenz. Ich habe Installationen gesehen, bei denen das Ändern von actimeo von 3 auf 120 Sekunden die Antwortzeit der Nextcloud-Oberfläche um den Faktor 5 verbessert hat. Allerdings auf Kosten einer geringeren Konsistenz bei Dateiänderungen von außerhalb – das muss man abwägen.
Object Storage (S3-kompatibel) wird immer beliebter, weil es horizontal skalierbar und oft günstiger ist. Nextcloud unterstützt S3 als Primärspeicher ('objectstore' => array('class' => 'OC\\Files\\ObjectStore\\S3', ...)). Das kann die lokale Festplatte entlasten, birgt aber auch Tücken: Latenzen zum S3-Server, Kosten pro API-Aufruf und – ein Punkt, der oft übersehen wird – die fehlende Unterstützung von Datei-Locks über S3. Das bedeutet, dass gleichzeitige Schreibzugriffe auf dieselbe Datei zu Konflikten führen können, wenn man nicht zusätzlich ein Locking über Redis aktiviert. Wer S3 einsetzt, sollte auch die s3.use_multipart_copy und s3.upload_part_size anpassen. Standardmäßig benutzt Nextcloud beim Kopieren großer Dateien (über 1 GByte) multipart Uploads – das ist gut, aber die Part-Größe sollte an die Netzwerkgegebenheiten angepasst werden. Eine zu kleine Part-Größe führt zu vielen API-Aufrufen, eine zu große zu langen Wartezeiten bei Fehlern. Erfahrungswert: 64 MByte pro Part ist ein vernünftiger Kompromiss.
Ein weiterer Tipp für Storage-Performance: Die Verwendung von Primary Storage mit 'local' und einem schnellen SSD-Cache (z. B. via LVM-Cache oder bcache) für die Metadatenverzeichnisse. Nextcloud speichert kleine Dateien wie Vorschaubilder und Metadaten in appdata_*-Verzeichnissen. Diese sollten auf schnellem Speicher liegen. Wer eine NAS-Lösung mit HDDs verwendet, kann durch Auslagerung der thumbnails– und appdata-Ordner auf eine kleine SSD (etwa per Symlink) enorme Verbesserungen erzielen, ohne gleich das gesamte Storage umzuziehen.
Das unsichtbare Workhorse: Cronjobs richtig konfigurieren
Nextcloud erledigt viele Hintergrundaufgaben im Cron-Modus: das Versenden von Benachrichtigungen, das Generieren von Vorschaubildern, das Ausführen von geplanten App-Jobs und vor allem die Datei-Scan-Operationen. Der Standardmodus ist „Ajax-basiert“, bei dem der Cron bei jedem Seitenaufruf angestoßen wird. Das ist für kleine Installationen akzeptabel, aber unter Last ein Performance-Grab. Besser: Der „Cron“-Modus (System-Cron) oder der empfohlene „systemd“-Modus. Dabei wird regelmäßig ein PHP-Skript (cron.php) über den System-Cron-Dienst aufgerufen. Die Latenz ist minimal, und die Last wird gleichmäßig verteilt. Ein häufiger Fehler: Der Cron wird zu häufig ausgeführt (alle Minute), aber die Jobs stapeln sich, weil die Ausführung länger dauert als ein Intervall. Dann arbeitet Nextcloud parallel an mehreren Cron-Durchläufen, was zu Konflikten und erhöhter CPU-Last führt. Die Lösung: Die cron.php sollte nur dann einen neuen Durchlauf starten, wenn der vorherige beendet ist. Das lässt sich mit einem einfachen Lockfile oder der Verwendung des Nextcloud-eigenen Hintergrundjob-Managers erreichen. In der Praxis hat sich ein Intervall von 5 bis 10 Minuten bewährt – je nach Menge der anstehenden Jobs. Wer viele Benutzer hat, kann auch auf 2 Minuten gehen, muss aber die Serverlast im Auge behalten.
Ein weiterer Cron-bezogener Tipp: Vorschaubilder generieren. Nextcloud erstellt bei jedem Datei-Upload ein Thumbnail. Das kann bei tausenden Bildern zu massiven CPU-Spikes führen. Mit der App „Preview Generator“ kann man Vorschaubilder gezielt für alle vorhandenen Dateien und in regelmäßigen Intervallen generieren lassen. Das entlastet die Interaktion auf der Oberfläche, denn dann muss das Thumbnail nicht erst bei der Anzeige erstellt werden. Allerdings erhöht das die Hintergrundlast. Man sollte die Generierung auf Zeiten mit wenig Nutzeraktivität legen – etwa nachts. Und die Anzahl der parallelen Thumbnail-Generierungsprozesse begrenzen ('preview_generator.max_programs' => 5). Sonst droht ein CPU-Collaps.
Client-Sync und Protokolle: Weniger ist manchmal mehr
Nextcloud ist nicht nur eine Webanwendung, sondern auch ein Sync-Client für Desktops und Mobilgeräte. Oft wird getunt, während die Clients überlastet sind. Ein Aspekt: Der Client verwendet standardmäßig das HTTP-Protokoll für Datei-Übertragungen. Bei vielen kleinen Dateien (z. B. E-Mails, Code-Repositories) ist die Latenz pro Datei der Flaschenhals. Nextcloud unterstützt seit Version 23 das sogenannte „Chunking“ für Uploads und die „File-Sync-Protocol“-Optimierung, die viele kleine Dateien in einer einzigen HTTP-Anfrage bündeln kann. Der Client kann über die Konfiguration (etwa maxChunkSize und targetChunkSize) angepasst werden. Wer oft mit vielen kleinen Dateien arbeitet, sollte die Chunk-Größe reduzieren (z. B. auf 1 MByte), damit die Übertragung effizienter wird. Bei großen Dateien (Videos, Archive) hilft ein größerer Chunk (10 MByte oder mehr), um die Anzahl der HTTP-Anfragen zu minimieren.
Ein oft übersehener Punkt ist die Komprimierung. Nextcloud unterstützt serverseitig die Komprimierung von HTTP-Antworten (gzip, brotli). Das reduziert das Datenvolumen bei der Übertragung von JSON-Daten, aber auch bei HTML-Seiten. Allerdings verbraucht es CPU-Ressourcen auf dem Server. In Zeiten von schnellen Internetverbindungen und leistungsfähigen Clients kann man die Komprimierung für bestimmte Ressourcen (etwa große Dateien) deaktivieren, um CPU zu sparen. Ein Kompromiss: brotli auf Dateien unter 1 MByte anwenden, für größere Dateien aus. In der Apache-Konfiguration oder Nginx-Einstellung umsetzbar.
Apps und Module: Das Unkraut jäten
Nextcloud hat einen riesigen App-Store. Viele Administratoren neigen dazu, jede vielversprechende App zu installieren – „könnte ja mal nützlich sein“. Aber jede App bringt eigene Datenbanktabellen, Cronjobs und möglicherweise eigene PHP-Erweiterungen mit. Das kostet Performance, selbst wenn die App nicht aktiv genutzt wird. Ein regelmäßiger „App-Frühjahrsputz“ ist angesagt. Nicht benötigte Apps deinstallieren – nicht nur deaktivieren. Deaktivierte Apps hinterlassen oft noch Daten in der Datenbank, was bei großen Installationen zu unnötigem Ballast führt. Ein Tool wie occ app:list und occ app:remove hilft.
Besonders hungrige Apps sind die Text- und Office-Suiten (Nextcloud Office, Collabora, OnlyOffice), die Kollaborationsmodule und die Volltext-Such-Apps (Elasticsearch/Fulltextsearch). Letztere erfordern einen eigenen Such-Index, der regelmäßig aktualisiert werden muss. Wer keine umfangreiche Volltext-Suche benötigt, sollte sie abwählen. Die Standard-Suche über die Datenbank reicht für die meisten Anwendungsfälle aus. Auch die Aktivitäten-App kann unter Last problematisch sein, weil sie bei jeder Dateiänderung einen Datenbankeintrag erzeugt. Für große Teams mit vielen Änderungen kann man die Anzahl der gespeicherten Aktivitäten begrenzen ('activity_expire_days' => 30).
Netzwerk und Lastverteilung: Was bringt ein Load Balancer?
Wenn der einzelne Server nicht mehr ausreicht, wird es Zeit für horizontale Skalierung. Nextcloud unterstützt die Aufteilung auf mehrere Webserver hinter einem Load Balancer. Das klingt elegant, bringt aber neue Herausforderungen. Der wichtigste Punkt: Der Storage muss für alle Server zugänglich sein – meist ein gemeinsames NFS oder ein Object Store. Dann muss Redis für Sessions und Cache zentral installiert sein. Und die Datenbank wird zum Single Point of Failure. Also auch hier eine Master-Master- oder Master-Slave-Konfiguration? Nextcloud kann mit einer lesenden Datenbank-Replikation umgehen, indem man in der config.php 'db_replica_connection' definiert. Das entlastet den Master bei Lesezugriffen. Aber Vorsicht: Die Replikation muss sehr aktuell sein, sonst liest ein Server veraltete Daten. Bei asynchroner Replikation kann das zu Inkonsistenzen führen. Besser ist eine synchrone Replikation (z. B. Galera-Cluster mit MariaDB). Allerdings steigt die Latenz dann bei Schreibzugriffen. Auch hier gilt: Abwägung zwischen Konsistenz und Geschwindigkeit.
Ein Load Balancer kann auch SSL-Terminierung übernehmen. Das entlastet die Webserver von der Verschlüsselung. Allerdings steigt die Komplexität. Für die meisten Betriebe reichen 2 bis 4 Server aus. Alles darüber hinaus ist eher etwas für Hosting-Provider mit vielen Tausend Benutzern. Interessant ist, dass Nextcloud selbst mit einem Load Balancer nicht die Performance linear zur Anzahl der Server steigert, weil die Datenbank und der Storage oft die limitierenden Faktoren bleiben. Also zuerst die Engpässe dort beheben, bevor man mehr Server aufsetzt.
Monitoring: Das Auge des Administrators
Ohne Messung kein Tuning. Wer seine Nextcloud-Installation optimieren möchte, kommt um ein gutes Monitoring nicht herum. Das fängt bei den Basis-Metriken an: CPU-Auslastung, RAM-Nutzung, I/O-Wartezeiten, Netzwerk-Latenz. Aber Nextcloud-spezifische Werte sind noch wichtiger. Die occ-Befehle occ status, occ db:add-missing-indices (ein unterschätzter Befehl!), occ dav:sync-birthday-calendar – das sind Wartungsaufgaben, die regelmäßig ausgeführt werden sollten. Vor allem occ db:add-missing-indices kann bei älteren Installationen enorme Verbesserungen bringen, weil Nextcloud mit neuen Versionen oft Indizes nachrüstet, die bei der Erstinstallation fehlten. Das sollte man nach jedem Major-Update ausführen. Auch occ files:scan --all kann bei Inkonsistenzen helfen, aber unter Last ist das ein Performance-Killer. Lieber nachts ausführen.
Für das Live-Monitoring empfehle ich Tools wie Netdata oder Prometheus mit dem Nextcloud-Exporter. Das zeigt auf einer Dashboard-Oberfläche, wie viele PHP-Prozesse laufen, wie schnell die Datenbank antwortet und wie viele Redis-Verbindungen offen sind. Man kann Alarme einrichten, wenn die durchschnittliche Antwortzeit der Datenbank über 50 ms steigt oder die PHP-FPM-Warteschlange zu lang wird. Das sind oft die ersten Anzeichen für einen Engpass. Ein interessanter Aspekt: Viele Administratoren unterschätzen die Bedeutung der Netzwerklatenz zwischen Server und Datenbank. Wenn die Datenbank auf einem anderen Rechner läuft, kann die Latenz von 0,1 ms auf 1 ms steigen – das multipliziert sich bei tausend Abfragen pro Sekunde. Also lieber Datenbank und Nextcloud auf demselben Server lassen, solange es die Hardware erlaubt. Oder eine dedicated Datenbank mit schnellem Netzwerk (10 GbE).
Kleine Helfer: Konfigurationsdetails, die den Unterschied machen
Es gibt eine Reihe von Parametern in der config.php, die wenig Beachtung finden, aber signifikante Wirkung haben. Zum Beispiel 'default_language' => 'de' – das klingt trivial, aber Nextcloud lädt standardmäßig Übersetzungen für alle installierten Sprachen. Durch Setzen einer Standardsprache reduziert sich der Overhead. Ähnlich: 'skeletondirectory' => '' – wenn man kein Verzeichnis mit Standarddateien für neue Benutzer benötigt, kann man den Pfad entfernen. Das erspart den Dateikopie-Vorgang bei jeder Neuanlage. 'versioninquiry' => false verhindert, dass Nextcloud bei jedem Aufruf die neueste Version vom Nextcloud-Server abfragt – das spart Latenz und schont die Privatsphäre.
Ein weiterer Punkt: Die Logging-Einstellungen. Im Standardprotokolliert Nextcloud auf level => 2 (Warnungen). Wer unter hoher Last debuggt, sollte auf level => 0 nur Fehler reduzieren. Und die log_rotate_size auf einen Wert wie 100 MByte setzen, damit die Log-Dateien nicht unendlich wachsen. Das vermeidet unerwartete Speicherprobleme auf der Festplatte.
Der Faktor Mensch: Tuning als kontinuierlicher Prozess
Das Fazit nach dreißig Jahren IT-Erfahrung: Nextcloud-Tuning ist kein einmaliges Projekt, sondern ein kontinuierlicher Kreislauf. Man behebt einen Engpass, und drei Monate später taucht ein neuer auf – weil die Benutzerzahl gestiegen ist, weil eine neue App installiert wurde, weil der Speicher voller wird. Deshalb: Nach jedem größeren Update die Indizes überprüfen, die Cache-Konfiguration validieren und die Cron-Jobs auf Stau prüfen. Und immer ein Backup parat haben, bevor man an der Konfiguration schraubt. Denn nichts ist ärgerlicher als eine optimierte, aber unbrauchbare Nextcloud.
Ein letzter Hinweis, der oft vergessen wird: Das Tuning für den Desktop-Client ist genauso wichtig wie das Serverside. Viele Benutzer verwenden den Client mit Standardeinstellungen, die für schnelle Internetverbindungen optimiert sind. Wer in einer Umgebung mit hoher Latenz oder geringer Bandbreite arbeitet, sollte im Client die Beschränkung der Upload/Download-Geschwindigkeit aktivieren (Upload Bandwidth und Download Bandwidth). Und die Anzahl der parallelen Übertragungen (Default: 5) reduzieren. Das verhindert, dass der Client selbst zum Engpass wird, weil er zu viele Verbindungen gleichzeitig aufbaut und den Router überlastet. Auch die Einstellung Throttle Transfer kann helfen, den Sync im Hintergrund laufen zu lassen, während der Benutzer andere Programme verwendet.
All das sind keine Geheimtipps aus der Versenkung, sondern erprobte Methoden, die in der Praxis funktionieren. Wer sie umsetzt, wird seine Nextcloud-Installation merklich flotter erleben – und das mit vertretbarem Aufwand. Denn letztlich geht es nicht darum, jeden einzelnen Parameter bis ins letzte Prozent zu optimieren, sondern darum, die großen Bremsen zu identifizieren und zu beseitigen. Der Rest kommt dann fast von selbst.
Und wenn man dann abends das Dashboard aufruft und die Antwortzeiten unter 200 Millisekunden liegen, dann weiß man: Die Arbeit hat sich gelohnt. Bis zum nächsten Update.