wir rollen naechste Woche Nextcloud fuer die Lehrer aus, Installation steht, haben aber noch nichts bzgl. Optimierung (Caching usw.) gemacht.
Was mir auffaellt ist, dass Nextcloud schon recht traege reagiert, selbst wenn nur eine Person am Rumstochern ist.
Schau ich mir das mit top, htop, iotop, iftop und Konsorten an, dann passiert da eigentlich ueberschaubar wenig, CPU-Last ist aber sporadisch recht hoch, aber bei einer Person wird kein Kern auf 100% gebracht.
Traege ist das aber trotzdem.
Woran liegt’s?
Wo wird die Zeit verbraten?
Ist das bei Euch flott zu bedienen?
An welchen Schraeubchen lohnt es sich zu drehen?
Redis als Cache ist ganz wichtig UND PHP op_cache aktiviereen, PHP-FPM pm.max_children
hochschrauben(habe 350) und php gut RAM zuweisen (2GB memorylimit) und auch achten dass die DB Anbindung nicht der Flaschenhals wird. (Anzahl gleichzeitiger Verbindungen hochsetzen).
Habe Apache mit nginx als proxy im Einsatz, nginx cached die statische Daten und gibt die deutlich schneller aus. (ist historisch gewachsen, eventuell auch nur mit nginx arbeiten)
Performance ist sehr wichtig, gerade bei vielen Nutzern. Habe absolut keine Perfomance Probleme, auch mit über 200gleichzeitigen Nutzer und speicherlastigen Modulen wie Talk und OnlyOffice.
Ich habe ein Sicherheitsskript gebastelt, dass im Notfall (RAM über 80% belegt), die php-fpm neustartet. Am Anfang der Krise kam das noch öfters zum Einsatz, da Talk noch ein paar Speicherbugs hatte, seit dem die behoben sind, flutscht alles recht gut.
Du meinst also Redis UND OPCache beides?
Momentan habe ich nur OPCache.
Kannst du mal deine bzw. aus deiner Erfahrung sinnvolle Werte in der php.ini posten?
Bei uns wird NC zwar kaum genutzt und ich habe die Befürchtung, dass sich daran auch nichts ändern wird (ich habe mein Leid / meinen Frust hier schon sehr oft kund getan ), aber da ich NC auch privat nutze und die Hoffnung bekanntlich doch zuletzt stirbt, hier mal, was ich in der php.ini eingestellt bzw. woran ich bislang geschraubt habe:
Bei geringer Nutzung merke ich bislang keinen Performanceunterschied. Aber gut, vielleicht kommt der erst bei vielen Usern parallel zum Tragen.
Auch gelingt es mir nicht, Redis als Unix socket zu nutzen, obwohl alles auf dem selben Server läuft. Ich mache dazu aber vielleicht besser einen neuen Thread.
Hallo zusammen, @Bellm und ich habe das hier schon bequatscht: Nextcloud / php (fpm) tuning und auch in noch einem anderen Thread.
Da findet ihr eine Zusammenfassung weiter unten und die Kommentare von @Bellm
Du meinst also Redis UND OPCache beides?
Momentan habe ich nur OPCache.
Ja, BEIDES.
OP Cache ist für die php Skripte zuständig, diese werden im Cache vorgehalten und müssen daher nicht immer erst von der Festplatte gelesen und kompiliert werden, sondern können direkt vom RAM falls notwendig kompiliert und dann ausgeführt werden
Redis ist eher ein Cache für Dateien bzw das Dateisystem. Hier werden Dateien / Ordner zum Schreiben gesperrt und man ist hier durch den Cache auch schneller als auf der Festplatte. Bei ein paar Usern kommt das nicht zur Geltung, aber so bald es signifikant mehr werden, merkt man die Entlastung dank des Caches.
Kannst du mal deine bzw. aus deiner Erfahrung sinnvolle Werte in der php.ini posten?
pm=ondemand
pm.maxchildren=350 (bei 32GB RAM)
pm.max_requests= 1000
Das kommt aber auf den Server, die benutzten Module etc. an
Bei uns wird NC zwar kaum genutzt und ich habe die Befürchtung, dass sich daran auch nichts ändern wird (ich habe mein Leid / meinen Frust hier schon sehr oft kund getan ), aber da ich NC auch privat nutze und die Hoffnung bekanntlich doch zuletzt stirbt, hier mal, was ich in der php.ini eingestellt bzw. woran ich bislang geschraubt habe:
Hier würde ich auf 1 GB oder 2GB gehen, ist ja nur ien maximal Limit. memory_limit = 2048M
und auch achten dass die DB Anbindung nicht der Flaschenhals wird. (Anzahl gleichzeitiger Verbindungen hochsetzen). Auf wie viel? Und in welcher Datei? (Ich weiß, könnte ich auch selbst suchen, aber wenn es jemand grad schon parat hat )
Gerne doch. Wie gesagt, viele der Sachen kommen erst deutlich zum Tragen bei vielen parallelen Nutzern.