#4039 closed Aufgabe (erledigt)
Funktion der Memory-Caches prüfen
| Reported by: | Rüdiger Kupper | Owned by: | Rüdiger Kupper |
|---|---|---|---|
| Priority: | bald erledigen | Milestone: | Nextcloud: Optimierungen |
| Component: | Webdienst: Kepler-Cloud | Severity: | beeinträchtigt keinen Unterricht |
| Keywords: | Cc: | bau |
Description
Für acpu und refis gibt es php-Skripge, welche die Funktiom zusammemfassen. Die funktionieren ähnlich wie phpinfo. Die Skripte lassen sich derzeit nur aufrufen, wenn man den document root umbiegt, was die Cloud für alle anderen Nutzer unerreichbar macht.
Also: nachts machen.
- @bau
- gibt es einen anderen Weg, php-Skropte für die Administratoren erreichbar zu machen, ohne den document root zu ändern?
Change History (10)
comment:1 by , 5 years ago
| Priority: | normal → höchste |
|---|---|
| Status: | new → accepted |
comment:2 by , 5 years ago
comment:3 by , 5 years ago
Die Skripte zur Überprüfung der Cache-Funktion liegen in /var/www/, um sie zu nutzen muss man also den Document-Root dorthin umbiegen. (Wodurch Nextcloud nicht mehr erreichbar ist. – Wäre schön, wenn wir hier eine Lösung dänden, dass beides gleichzeitig geht.)
Die Überprüfung hat ergeben, dass der als lokaler Memory-Cache empfohlene Acpu zwar installiert und aktiviert ist (laut phpinfo). Er wird aber ganz offenbar nicht genutzt: Alle Statistik-Daten stehen auf 0, auch die "Uptime" steht auf 0 fest. Googlen hat ergeben, dass Acpu offenbar nicht geeignet ist, wenn CGI oder FastCGI für die PHP-Anbindung an Apache genutzt wird. Und ich glaube, wir nutzen FastCGI (@bau: richtig?). Hier wird für jeden PHP-Aufruf ein neuer PHP-Prozess gestartet mit eigenem Apcu – und damit weiß das Apcu in dem einen Prozess nicht, was das andere weiß. Und lebt auch nur so lange, bis der Prozess abgeschlossen ist.
Acpcu spielt seine Fähigkeiten aus, wenn man PHP-FPM einsetzt – hier gibt es nur einenPHP-Prozess, der bei einer Anfrage geforkt wird, so dass alle Forks den selben Memorycache nutzen können. PHP-FPM ist standard bei nginx, bei Apache muss es erst eingerichtet und konfiguriert werden. Das wäre eine zukünftige Optimierung.
Ich habe den lokalen Memory-Cache nun also wieder auf Redis umgestellt, was auch schon das transactional file locking übernimmt. Redis läuft in einem getrennten Prozess und wird über ein UNIX-Socket angesprochen, ist also von allen PHP-Prozessen erreichbar. Redis gilt als nicht ganz so performant wie Apcu, doch besser als ein nicht genutztes Apcu ist es sicher ;-).
comment:4 by , 5 years ago
Manchmal ist das hier echt Star-Trek-Technobubble vom feinsten :D.
Kann das zu?
comment:5 by , 5 years ago
| Cc: | removed |
|---|---|
| Priority: | höchste → normal |
comment:6 by , 4 years ago
| Resolution: | → bleibt so |
|---|---|
| Status: | accepted → closed |
comment:7 by , 3 years ago
| Resolution: | bleibt so |
|---|---|
| Status: | closed → reopened |
Ich würde mal testen, auf php-fpm umzustellen. Dann die Memory-Caches nochmal vergleichen
comment:8 by , 3 years ago
| Status: | reopened → accepted |
|---|
comment:9 by , 3 years ago
| Cc: | added |
|---|---|
| Resolution: | → erledigt |
| Status: | accepted → closed |
Beide Caches funktionierrn auch mit mod-php, die Apache-Prozesse teilen sich einen apcu-Cache (und redis ebenso). Die Stazusskripte müssen unterhalb des selben Document-Root liegen wie Nwxtcloud, also /var/www/nextcloud/...
Dort können die Skripte leider nicht dauerhaft liegen, weil sich sonst der NC-Updater beschwert, dass es fremde Dateien gibt und seinen Dienst verweigert. Daher können die Skripts immer nur vorübergehend dorthin kopiert werden und müssen zum nächsten Update wieder entfernt werden.
Jedenfalls funktioniert APCu für die Apache-Prozesse umd jeweils für einen Cron-Prozess. Update auf php-fpm ist dazu nicht nötig, allerdings wohl für HTTP/2 erforderlich (siehe eigenes Ticket).
NC nutzt nun wie empfohlen APCu für lokales Caching.
Siehe https://blog.admin-intelligence.de/nextcloud-durch-caches-beschleunigen/