Ein zentraler Stolperstein
Nextcloud ist längst mehr als eine private Dropbox-Alternative für Technikfreaks. Aus dem kleinen File-Sharing-Projekt ist eine ernsthafte Plattform geworden: Kalender, Kontakte, Office-Dokumente, Videokonferenzen und sogar Gruppenlaufwerke – all das sauber unter eigener Kontrolle. Genau das überzeugt IT-Verantwortliche, egal ob im Mittelstand, bei öffentlichen Auftraggebern oder in der Selbstverwaltung. Doch je mehr Module man nutzt, desto stärker rückt eine Frage ins Zentrum: Wie lässt sich die Nextcloud Performance optimieren, ohne ständig teurere Hardware nachzuschieben?
Die Erfahrung vieler Admins ist immer wieder dieselbe. Nach dem ersten Setup läuft die Instanz überraschend flott. Irgendwann kommen zwanzig, fünfzig, zweihundert Nutzer dazu, die Zahl der Dateien wächst, die Vorschaubilder ballern auf die Festplatte, und auf einmal dauert schon der Seitenaufbau mehrere Sekunden. Wer dann unvorbereitet in die Tiefen der Serverkonfiguration steigt, findet eine Fülle an Hebeln – aber nicht jeden Hebel, der wirklich etwas bringt.
Dieser Artikel geht die üblichen Flaschenhälse systematisch durch. Nicht jede Instanz braucht alle Maßnahmen, und ein paar Einstellungen kann man je nach Einsatzprofil getrost weglassen. Aber es schadet nicht, once genauer hinzusehen. Denn wer versteht, wie die Komponenten zusammenarbeiten, erspart sich später ärgerliche Notfallaktionen.
Warum Nextcloud so viel Aufmerksamkeit auf Ressourcen braucht
Nextcloud basiert auf PHP, einer Sprache, die für ihre Produktivität geschätzt wird, aber nicht gerade für extrem hohe Antwortraten berühmt ist. Dazu kommt eine Datenbank – meist MariaDB oder MySQL – die nahezu jede Operation begleitet. Jede Datei, jeden Kalendereintrag, jede Synchronisierung: Das System legt erst Metadaten in SQL-Tabellen ab, bevor es an den eigentlichen Dateiinhalt geht. Schon bei moderater Nutzung entstehen dadurch hunderte Abfragen pro Seitenabruf.
Ein zweiter Punkt ist die modulare Architektur. Nextcloud kann Apps wie Talk, Files oder Deck im selben Prozess ausführen, und standardmäßig sind etliche davon aktiviert. Jede App bringt eigene Routinen mit, die bei jedem Request geprüft werden. Das macht den Betrieb flexibel, führt aber auch dazu, dass die Systemlast nicht linear mit der Nutzerzahl steigt. Zwei- oder dreistellige Nutzerzahlen können schnell zu einem spürbaren Effekt führen – insbesondere, wenn der Webserver nicht ordentlich auf die Umgebung abgestimmt ist.
Ein weiterer oft unterschätzter Engpass ist die Storage-Technik. Nextcloud unterstützt zwar verschiedene Speicher-Backends, doch bei der Standardinstallation schreibt alles auf das lokale Dateisystem. Das ist solide, hat aber seine Tücken. Besonders wenn viele kleine Dateien synchronisiert oder Vorschauen erstellt werden, leidet die Performance der Platte. Hinzu kommt: Netzwerkfreigaben wie NFS oder SMB sind zwar praktisch, aber oft mit Latenzen unterwegs, die sich direkt in trägen Verzeichnislisten niederschlagen.
Nicht zuletzt spielt die Art der Nutzung eine Rolle. Ein Team, das ständig große Dateien austauscht, hat andere Anforderungen als eine Verwaltung, die nur Kalender und Kontakte über Nextcloud nutzt. Deshalb gehört die ehrliche Bestandsaufnahme zu Beginn einer Optimierung. Wer keine Lasttests macht und nicht misst, was die Instanz wirklich belastet, rät im Zweifel an den falschen Stellschrauben herum.
Erster Schritt: Caching und Memory-Backend
Wenn die Nextcloud-Instanz träge reagiert, lohnt ein Blick auf das Caching. Standardmäßig ist Nextcloud oft gar nicht oder nur mit einem sehr primitiven Cache konfiguriert. Dabei ist die Idee denkbar einfach: Häufig benötigte Informationen werden im Arbeitsspeicher vorgehalten, damit nicht jeder Abruf auf die Datenbank oder das Dateisystem zugreifen muss.
Nextcloud unterscheidet dabei verschiedene Ebenen. Da ist zum einen der lokale Cache, der auf einem einzelnen Server gespeichert wird. Zum anderen gibt es einen verteilten Cache, der bei mehreren Webservern im Verbund dafür sorgt, dass alle Knoten dieselben Informationen sehen. Dazu gehören Dateilock-Informationen, Sitzungsdaten und Dinge wie die Berechtigungsprüfung. Für die verteilte Ebene wird häufig Redis eingesetzt – ein In-Memory-Datenspeicher, der sich in der Praxis als robust und schnell erwiesen hat.
Für den lokalen Cache ist APCu eine gute Wahl. APCu ist eine PHP-Extension, die einen kleinen, schnellen Speicher für den einzelnen PHP-Prozess bereitstellt. Die Konfiguration in der config/config.php sieht dann unspektakulär aus, hat aber einen deutlichen Effekt:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'localhost',
'port' => 6379,
],
Achtung: Bei Verwendung von Redis für das Locksystem sollte man die Verbindungsdaten unbedingt gegenprüfen. Ein falscher Port oder ein geschützter Redis-Server kann sonst zu massiven Synchronisierungsproblemen führen. Wer bereits mit einem Redis-Cluster arbeitet, muss die Einstellungen entsprechend anpassen. Doch schon eine simple Redis-Instanz auf dem gleichen Rechner bringt bei den meisten Installationen deutliche Verbesserungen.
Interessant ist übrigens, dass Nextcloud ohne Redis auch bei kleinen Installationen nicht sauber funktioniert. Das wird vor allem dann sichtbar, wenn mehrere Clients gleichzeitig auf dieselbe Datei zugreifen. Ohne einen sauberen File-Lock-Mechanismus kommt es zu Konflikten, die sich im schlimmsten Fall als beschädigte Dateien äußern. Wer also die Performance optimieren möchte, sollte das nicht nur unter Geschwindigkeitsaspekten sehen, sondern auch unter Datenintegrität.
PHP-FPM und Opcache: Timing und Memory
Nextcloud-Code wird bei jedem Request von PHP ausgeführt. Dabei kommen hunderte Dateien ins Spiel, die gelesen, geparst und ausgeführt werden. Damit das zügig über die Bühne geht, führt PHP einen Opcode-Cache namens Opcache mit. Ist dieser nicht aktiviert, wird jede PHP-Datei bei jeder Anfrage erneut kompiliert – ein aufwendiger Prozess, der die Server-Last unnötig in die Höhe treibt.
Die Installation von php-opcache ist schnell erledigt. Wichtiger ist die Konfiguration. Neben den Klassikern wie opcache.enable=1 sollte man vor allem auf den Speicher schauen. Ein zu knappes Limit führt dazu, dass ältere Skripte aus dem Cache fliegen und beim nächsten Zugriff neu kompiliert werden müssen. Ein Wert von 256 MB oder 512 MB ist bei größeren Installationen keine Verschwendung. Auch die maximale Anzahl von Dateien sollte großzügig gewählt werden; wer hunderte Apps installiert hat, kann da schnell an Grenzen stoßen.
opcache.enable=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0
Kritisch ist der Parameter validate_timestamps. Im Produktivbetrieb sollte er auf 0 gesetzt werden, damit PHP nicht bei jeder Anfrage die Änderungszeit der Skripte prüfen muss. Allerdings bedeutet das auch: Nach einem Update der Nextcloud-Instanz muss man den PHP-FPM-Dienst neu starten, damit Änderungen wirksam werden. Das ist in der Regel kein Problem, sollte aber im Hinterkopf bleiben.
Bei PHP-FPM selbst sind die Einstellungen pm.max_children und pm.max_requests von zentraler Bedeutung. Nextcloud ist relativ speicherhungrig, und gerade die Vorschau-Generierung kann einzelne PHP-Prozesse für längere Zeit blockieren. Ein klassischer Fehler ist, max_children zu niedrig anzusetzen, wodurch sich Warteschlangen bilden. Zu hoch darf man aber auch nicht gehen, sonst kippt der Server unter der Speicherlast. Ein pragmatischer Orientierungswert: Zwei Webserver-Prozesse pro verfügbarem Gigabyte RAM plus etwas Reserve. Statt starrer Grenzen sollte man aber lieber Lasttests machen und die Werte den eigenen Mustern anpassen.
Wichtig ist außerdem, dass die PHP-Speichergrenze memory_limit großzügig genug ist. Nextcloud selber braucht im Normalbetrieb nicht viel, aber beim Upload großer Dateien oder beim Verarbeiten von Office-Dokumenten kann der Bedarf kurzzeitig in die Höhe schnellen. Wer hier auf 512 MB oder 1 GB setzt, liegt meist gut. Dass das Speicherlimit von PHP nicht die echte Memory-Nutzung einzelner Prozesse begrenzt, nur das für Skripte nutzbare Limit, sei der Vollständigkeit halber erwähnt – aber daran scheitern trotzdem viele Installationen.
Datenbank sinnvoll einstellen
Die Datenbank ist das Herzstück von Nextcloud. Alle Dateisysteme, Berechtigungen und Aktivitäten werden in Tabellen abgelegt, und wenn die Datenbank langsam arbeitet, hilft auch das beste Caching nicht mehr. Dabei gibt es zwei Ebenen: die Konfiguration des Datenbank-Servers selbst und die Art, wie Nextcloud mit der Datenbank redet.
Bei MariaDB und MySQL lohnt es sich, den InnoDB-Puffer großzügig zu bemessen. Er hält häufig genutzte Index- und Datenblöcke im Arbeitsspeicher. Für eine Nextcloud mit ein paar hunderttausend Dateien sollte der Puffer nicht unter 1 GB liegen, besser mehr. Wichtig ist auch der Parameter innodb_io_capacity beziehungsweise innodb_io_capacity_max. Wer NVMe-SSDs verwendet, darf hier deutlich höher gehen als bei alten Drehscheiben. Dadurch kann die Datenbank ihre Hintergrundschreibvorgänge schneller erledigen, ohne die Platte zu überfordern.
innodb_buffer_pool_size = 4G innodb_io_capacity = 1000 innodb_io_capacity_max = 2000 innodb_flush_log_at_trx_commit = 2
Ein heißer Kandidat für Verzögerungen ist außerdem das Protokollieren. Viele Standardkonfigurationen schreiben bei jeder Transaktion sofort auf die Platte. Das ist sicher, kostet aber Performance. Wer die Einstellung innodb_flush_log_at_trx_commit auf 2 setzt, erreicht einen guten Kompromiss zwischen Geschwindigkeit und Konsistenz. Das Risiko, bei einem Stromausfall einige Transaktionen zu verlieren, ist bei einer Nextcloud-Instanz überschaubar – wer es absolut sicher braucht, sollte es allerdings nicht tun.
Nicht zuletzt sollte man der Datenbank erlauben, lang laufende Abfragen zu sehen. Der Slow-Query-Log ist in der Praxis ein wertvolles Werkzeug, um Nextcloud-Performance-Probleme zu erkennen. Wenn zum Beispiel die Tabelle oc_filecache bei jeder Suche mehrere Sekunden benötigt, fehlt vermutlich ein Index. Nextcloud liefert dafür keine eingebaute Diagnose, aber ein Blick auf die laufenden Prozesse zeigt meist schnell, wo es klemmt.
Ein Wort zur Datenbank-Engine: Nextcloud unterstützt auch PostgreSQL. Wer von MySQL zu PostgreSQL wechseln möchte, findet dafür inoffizielle Migrationsskripte, doch das ist kein Sonntagsspaziergang. In den meisten Fällen ist eine gut konfigurierte MariaDB völlig ausreichend – aber man sollte die Datenbank nicht als lästiges Anhängsel betrachten. Sie verdient eine eigene Wartung und regelmäßige Checks.
Speicher, Objekt-Speicher und die richtige Verteilung
Nextcloud speichert Dateien normalerweise im Verzeichnis data, das wiederum auf einem Volume liegt. Solange die Größe überschaubar ist, funktioniert das hervorragend. Bei mehreren zehn Terabyte wird es allerdings unübersichtlich, und auch die Performance kann leiden. Abhilfe schafft der Einsatz von Objektspeicher wie S3 oder OpenStack Swift, den Nextcloud seit Langem nativ unterstützt. Dateiinhalte wandern dann nicht mehr auf die lokale Platte, sondern in einen objektbasierten Storage – was die Skalierung erheblich vereinfacht.
Interessant wird es, wenn man nicht alles umziehen will. Nextcloud kann einzelne Ordner auf externen Speicher auslagern oder einen primären Objektstorage mit lokalem Cache kombinieren. Letzteres klingt verlockend: Die eigentlich Dateien liegen billig im Objekt-Speicher, während häufig genutzte Dateien lokal gehalten werden. Doch die Praxis zeigt, dass die Konfiguration anspruchsvoll ist. Jedes falsch gesetzte External-Storage-Mount kostet am Ende mehr Zeit als der Nutzen, den es bringt.
Ein grundlegendes Schema ist jedoch sinnvoll: Metadaten und Datenbank auf schnellen SSDs, Dateiinhalte auf größeren, aber etwas langsameren Volumes – oder eben im Objektspeicher. Dass die lokale Platte fast immer schneller ist als ein Objekt-Store über das Netz, ist eine Binsenweisheit. Wer also für fünf Benutzer eine Nextcloud betreibt, braucht keinen S3-Bucket, sondern eine gute NVMe-SSD. Wer fünfhundert Benutzer bedient, freut sich dagegen über die Flexibilität von Objektspeicher-Lösungen, die man unabhängig vom Nextcloud-Server erweitern kann.
Bei großen Verzeichnissen lohnt es sich, das Dateisystem mit Blick auf Inodes zu wählen. Nextcloud legt sehr viele kleine Dateien an – Vorschauen, App-Caches, temporäre Dateien. Ein Dateisystem wie ext4 mit ausreichend Inodes ist da im Vorteil. XFS gilt ebenfalls als solide. Btrfs neigt bei manchen Workloads zu Fragmentierung, ist für Nextcloud aber nicht grundsätzlich ungeeignet. Wichtig ist vor allem, die Warnungen des Dateisystems nicht zu ignorieren und regelmäßig die Auslastung zu prüfen.
Vorschau-Generierung im Griff
Kaum eine Funktion bringt Nextcloud-Server so schnell ans Limit wie die automatische Vorschau von Bildern und Dokumenten. Jedes Mal, wenn ein Benutzer einen Ordner mit vielen Bildern öffnet, erstellt Nextcloud für jede Datei eine Vorschau, sofern das nicht bereits geschehen ist. Sind die Dateien groß, etwa 40-Megapixel-Fotos, kann die Verarbeitung pro Datei mehrere Sekunden dauern. Bei hunderten Dateien ist der Server danach erst einmal beschäftigt.
Dabei zeigt sich, dass Nextcloud einiges tun kann, um den Schaden zu begrenzen. In der Config gibt es die Schlüssel preview_max_x und preview_max_y, die die maximale Größe der Vorschau begrenzen. Wer Vorschauen nur für die Anzeige in der Web-GUI braucht, kommt mit 1024 px meist gut aus. Auch enable_previews kann für bestimmte Dateitypen eingeschränkt werden. So kann man etwa festlegen, dass keine Vorschau für Video- oder PDF-Dateien erzeugt wird, wenn das nicht unbedingt nötig ist.
'enable_previews' => true, 'preview_max_x' => 1024, 'preview_max_y' => 1024, 'preview_max_filesize_image' => 50, 'preview_max_memory' => 512,
Ein wartungsarmer Ansatz ist, die Vorschauen vorab als Hintergrundjob erzeugen zu lassen, statt sie beim ersten Benutzerzugriff zu erstellen. Dafür gibt es das Kommando occ preview:generate, das sich per Cron regelmäßig ausführen lässt. Beispielsweise kann man jede Nacht die Vorschauen der letzten 1000 geänderten Dateien erstellen lassen. Das sorgt für einen gleichmäßigen Load und hält die interaktiven Zugriffe schlank. Wer die Vorschauen nicht unbedingt braucht, kann sie auf einem separaten Volume auslagern oder in den Objektspeicher legen.
Ein Detail am Rande: Die Vorschau-Generierung verbraucht nicht nur CPU, sondern auch eine Menge Arbeitsspeicher. Wenn man eine 50-MB-Datei in eine Vorschau von 256 px verwandeln will, muss der ganze Bildinhalt durch PHP gehen. Da ist es kein Wunder, dass manche Instanzen mitten im Betrieb immer wieder kurze Aussetzer haben. Wer hier Abhilfe schafft, gewinnt meist mehr, als an jeder anderen Stelle der Applikation.
Hintergrundjobs richtig planen
Nextcloud benötigt für viele Aufgaben im Hintergrund: das Löschen alter Versionen, die Aktualisierung von Suchindizes, das Versenden von Benachrichtigungen, die Pflege der Aktivitäten. Standardmäßig ist der Cron-Job in Nextcloud so eingestellt, dass er bei Web-Requests läuft. Das heißt, ein Benutzer löst beim Seitenaufruf nebenbei auch die Hintergrundjobs aus. Das funktioniert, führt aber bei größeren Installationen zu Lastspitzen, weil der Job im selben PHP-Prozess läuft und den Seitenaufruf verzögert.
Als Alternative bietet Nextcloud einen systemnahen Cron an, der über das Betriebssystem gesteuert wird. Dazu setzt man in der Config 'backgroundjobs_mode' => 'cron' und ruft per crontab die cron.php aus dem Nextcloud-Verzeichnis auf. Der Aufruf sollte nicht häufiger als alle 5 Minuten passieren, sonst verpufft die Entlastung. Auf diese Weise laufen die Jobs auf dem PHP-CLI-SAPI, nicht im Webserver, was die Antwortzeiten spürbar verbessert.
*/5 * * * * /usr/bin/php -f /var/www/nextcloud/cron.php
Wichtig ist, dass dieser Cron auf einem Rechner läuft, der die Nextcloud-Instanz erreicht. Bei einem Cluster sollte man dafür sorgen, dass nicht alle Knoten gleichzeitig denselben Job ausführen. Nextcloud hat dafür eine Job-Queue, die auf Basis der Datenbank arbeitet. Solange nur ein Cron-Prozess läuft, ist das sauber. Wer auf mehreren Servern cron.php aufruft, muss mit Sperren arbeiten oder einen Load-Balancer davor schalten.
Ein weiteres Thema sind die Datei-Versionen und der Papierkorb. Nextcloud kann für jede Datei mehrere Versionen vorhalten, und standardmäßig sind die Limits großzügig bemessen. Wenn viele Benutzer regelmäßig Office-Dokumente bearbeiten, können so im Hintergrund Hunderte GB zusammenkommen, die dann wieder aus der Datenbank verschwinden müssen. Die Einstellungen dazu lassen sich über die Config anpassen. Wer die Aufbewahrungsdauer reduziert, entlastet sowohl die Platte als auch die Datenbank, ohne das Nutzungserlebnis groß zu beeinträchtigen.
Webserver, HTTP/2 und moderne Kompression
Die Kommunikation zwischen Browser oder Desktop-Client und dem Server läuft über HTTP. Auch hier gibt es Stellschrauben, die man nicht vernachlässigen sollte. Zentral ist die Nutzung von HTTP/2 beziehungsweise inzwischen HTTP/3. Vor allem bei vielen kleinen Dateien, die Nextcloud in der Weboberfläche lädt, spart HTTP/2 eine Menge Zeit, weil es die parallelen Requests über eine einzige Verbindung schickt. Nginx und Apache können das mit entsprechenden Modulen.
Daneben spielt die Kompression eine Rolle. Textbasierte Inhalte wie JavaScript, CSS und SVG sollten komprimiert übertragen werden – klassisch mit Gzip oder besser mit Brotli. Die Einsparungen liegen bei 20 bis 30 Prozent Vergleich zu Gzip, und die Browser verstehen Brotli heute praktisch alle. Einfacher gesagt: Wer seine Nextcloud mit Brotli ausliefert, sorgt dafür, dass die Weboberfläche schneller reagiert, ohne dass der Server dafür viel Aufwand treiben muss.
gzip on; gzip_types text/css application/javascript application/json image/svg+xml; gzip_min_length 1000;
Wer Nginx verwendet, sollte außerdem sicherstellen, dass der FastCGI-Puffer groß genug ist. Nextcloud-Funktionen wie der Sync-Status liefern mitunter lange Antworten, die andernfalls auf die Platte zwischengelagert werden. Mit Werten wie fastcgi_buffers 16 16k; und fastcgi_buffer_size 32k; lässt sich das meist entschärfen. Ein weiterer Punkt ist die Begrenzung der Dateigröße beim Upload: PHP und Webserver müssen client_max_body_size und upload_max_filesize gemeinsam anheben, sonst scheitern große Uploads ohne verständliche Meldung.
Ein interessanter Aspekt ist auch die TLS-Terminierung. Wenn der Server SSL-Zertifikate verwaltet und die Verbindung verschlüsselt, kann die CPU-Last insbesondere auf kleinen VPS spürbar werden. Die Verwendung von TLS 1.3, das die Anzahl der nötigen Handshakes reduziert, und einer effizienten Cipher-Suite hilft mehr, als man denkt. Zertifikate lassen sich mit Let’s Encrypt automatisch erneuern, das ist längst Standard. Aber die Konfiguration ist nicht überall optimal: Ältere Browser-Support-Listen zwingen manchmal zu unsicheren oder rechenintensiven Algorithmen.
Nicht zuletzt sollte man den Webserver selbst nicht als Ersatz für einen Load-Balancer missverstehen. Wenn die Nextcloud-Instanz mehrere hundert Benutzer hat, führt eine einzelne Nginx- oder Apache-Instanz oft zu Engpässen bei den offenen Verbindungen. Ein vorgelagerter HAProxy oder ein nginx als Reverse-Proxy für mehrere Worker-Knoten können Lastspitzen abfedern. Aber Vorsicht: Komplexität kostet Zeit und birgt neue Fehlerquellen. Für die meisten Installationen ist eine sauber konfigurierte Single-Server-Lösung mit ordentlichem Webserver immer noch die beste Wahl.
Monitoring, Messen und realistische Ziele
Wer die Nextcloud-Performance optimieren will, sollte vorher definieren, was eigentlich das Ziel ist. Eine Antwortzeit der Weboberfläche von unter zwei Sekunden? Ein Upload-Durchsatz von mindestens 100 Mbit/s? Oder eine Synchronisierung ohne Konflikte bei 50 Benutzern? Ohne messbare Kriterien hat jede Änderung nur Anekdotencharakter. Dabei hilft ein kurzer Blick auf die Logs und ein paar einfache Messungen mit curl oder Last-Test-Werkzeugen wie k6.
Ein guter Anfang ist die Beobachtung der Systemressourcen. Mit top oder htop sieht man, ob die CPU dauerhaft unter Last steht oder ob RAM fehlt. Ein Datenbank-Monitoring zeigt, welche Queries viel Zeit kosten. Nextcloud selbst protokolliert übrigens auch langsame Abfragen, sofern man das Log-Level entsprechend einstellt. In der config.php kann man mit 'loglevel' => 0 sehr viel Debug-Ausgabe erhalten – das sollte aber nicht permanent so bleiben, es bremst die Instanz zusätzlich.
Ein kleiner Lasttest mit mehreren parallelen Verbindungen auf die Login-Seite und auf den WebDAV-Endpunkt reicht oft aus, um ein Gefühl für den Server zu bekommen. Danach lässt sich gezielt an den Engpässen arbeiten. Wer zum Beispiel feststellt, dass der WebDAV-Upload bei 100 MB einbricht, sollte zuerst die PHP-Limits und die Netzwerk-Parameter prüfen, bevor er die Datenbank-Tuning jagt. Oft ist es ein Zusammenspiel mehrerer Faktoren, das über die tatsächliche Qualität entscheidet.
Dabei zeigt sich immer wieder, dass die Nextcloud-Gemeinde sehr unterschiedliche Erfahrungen mit Leistungsthemen hat. Die einen schwören auf Objektspeicher, die anderen auf eine schlanke MariaDB und viel RAM. Beide können recht haben – es kommt darauf an, wo die Flaschenhälse im Einzelfall liegen. Ein gehöriges Maß an Pragmatismus ist also angebracht. Empfehlungen aus Foren sollte man nachprüfen und in der eigenen Umgebung testen, statt sie blind zu übernehmen.
Fazit
Die Nextcloud Performance zu optimieren ist keine Hexerei, aber sie erfordert ein wenig Systemverständnis. Wer die wesentlichen Ebenen beachtet – PHP, Cache, Datenbank, Speicher, Webserver und Hintergrundjobs – bekommt in den allermeisten Fällen eine Instanz, die auch mit mehreren hundert Benutzern flüssig läuft. Entscheidend ist, nicht einfach irgendwelche Parameter zu verstellen, sondern die eigene Umgebung zu beobachten und gezielt einzugreifen.
Ein Satz zum Schluss, der manchmal unbequem klingt: Nextcloud ist kein Plug-and-play-System, das man einfach installiert und dann sich selbst überlässt. Die Plattform ist mächtig, aber dieser Mächtigkeit steht ein gewisser Administrationsaufwand gegenüber. Wer ihn nicht scheut, wird mit einer Infrastruktur belohnt, die in puncto Datenschutz und Souveränität kaum zu schlagen ist. Und wenn die Performance dann auch noch stimmt, lässt es sich sogar im Büro damit arbeiten.