Welche Profiling/Benchmarktools - Wordpress auf Rootserver ist aktuell zu langsam

  • Ich habe ein Wordpress welches auf einem Rootserver sehr langsam ist.
    Es hängt mit bestimmten Wordpressinstallationen zusammen. Hier wäre ein Profiling wirklich interessant.
    Das Panel, Joomla, und ein anderes frisches Wordpress sind etwas besser, aber auch nicht wirklich flott.


    Es sind Ladezeiten beim Backend Login oder Seitenübersicht von ca. 5-20 Sekunden.

    Das Frontend habe ich mit Caching ganz gut im Griff, aber auch nicht immer.

    Das Netcup Webhosting 8000 liefert bei mir viel bessere Ergebnisse.


    Dazu kommt, dass es ein sehr starker Server ist:
    RS 8000 G8 mit 64 GB Ram und 8 Core Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz (amd64)


    Wie kann ich am besten herausfinden woran es liegt?

    Server Benchmark, Php Profiling, Wordpress Profiling

    Bisher habe ich mal geschaut:
    - MySql Log hat keine Slow Queries.
    - Kaum Einträge in den Errorlogs.. nur ein paar Notices.
    - Keine 404 bei einzelnen Dateien oder in der Console mit dem Chrome Webmaster Tools zu sehen

    - Der Server ist bereits ca. 1 Jahr in Betrieb (Media wurde im Serverpanel schon des öfteren optimiert)
    - Der Server hat nur 2,5% CPU Auslastung laut Keyhelp Panel.

    - Der Server hat nur 5% RAM Auslastung laut Keyhelp Panel.
    - Einstellungen Standard außer:

    - PHP FPM is on demand mit pm.max_children 10, pm.max_request 1000

    - PHP hat memory_limit 200M, max_input_vars = 4252
    - Es sind wenige Kunden auf dem Server.
    - Server Neustart bringt ev. kurz was. Schwer zu sagen.


    Sonst alles Standard.
    Würde mich über Inputs freuen.

  • Gleiches Problem hier mit einem RS 2000

    Laut Statistik (im SCP) ist nichts am Limit, Support sagt auch: Alles OK


    Aber seit ein paar Tagen sind alle Wordpress-Installationen sehr langsam, zum Teil mit Generationszeiten um die 240 Sekunden (!).


    Ich suche mich auch schon ab...

    # uptime

    01:06:19 up 1 day, 47 min, 5 users, load average: 1,45, 0,98, 1,09


    # free -m

    total used free shared buff/cache available

    Mem: 16042 5737 1232 1838 9073 8144

    Swap: 16380 334 16046


    # df -h

    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

    udev 7,9G 0 7,9G 0% /dev

    tmpfs 1,6G 137M 1,5G 9% /run

    /dev/sda1 220G 135G 74G 65% /

    tmpfs 7,9G 16K 7,9G 1% /dev/shm

    tmpfs 5,0M 0 5,0M 0% /run/lock

    tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup

    tmpfs 1,6G 0 1,6G 0% /run/user/5014

    tmpfs 1,6G 0 1,6G 0% /run/user/0


    Wie geht man beim Suchen am Besten vor?

  • - PHP FPM is on demand mit pm.max_children 10, pm.max_request 1000

    Wird wohl nicht daran liegen, aber bei einem RS 8000 kannst du das deutlich nach oben schrauben.

    Ich habe bei 64 GB RAM hier ungestellt auf:

    Code
    pm = static
    pm.max_children = 150

    (Zudem starte ich php-fpm jede Nacht neu)


    Läuft auch alles sehr flott. :)

  • Noch ein Input von mir:
    Es gibt ein paar Profilingtools für PHP. Sie werden als Modul eingebunden und könnten z.B. ein problematisches Plugin identifizieren, indem sie zeigen wie lang sich der CPU mit einer bestimmten Funktion aufhält.

    Hier eine Übersicht:
    https://sandro-keil.de/blog/php-profiling-tools/

    1. Wordpress Profiler (Open Source)
    https://github.com/Rarst/laps

    2. Beispiel mit Video und Chrome Plugin unten für Blackfire Profiler Wordpress Debugging (leider Subscription und ein Windows Tutorial):
    https://maheshwaghmare.com/pro…-blackfire-for-wordpress/

    Ich habe damit noch keine Erfahrung und hatte auch zunächst an Serverbenchmarks gedacht.

  • Code
    pm = static
    pm.max_children = 150

    (Zudem starte ich php-fpm jede Nacht neu)


    Läuft auch alles sehr flott. :)

    Die Umstellung auf Static mit 80 Children hat eine starke Verbesserung gebracht! Top!

    Ich werde auch einen automatischen Restart von PHP-FPM einbauen.
    Muss man dies für jede PHP Version ausführen am Server (habe 7.3, 7.4 und 8.0).. bzw. wie findet man heraus welche Version?
    service php7.0-fpm restart

  • Ich habe den Verdacht, dass FPM Prozesse mit der Zeit voll und langsamer werden. Denn wenn ich die Einstellung (static, ondemand) ändere und quasi FPM neu gestartet wird ist es sehr schnell. Das klappt auch für einige Klicks, da ja diese Children sich mal füllen müssen.

    Und danach wird es gefühlt schnell wieder langsamer.

    Hierzu habe ich auch einen Artikel gefunden:

    Interessant zum Optimieren von PHP-FPM:
    "You can use pm.max_requests = 0 with static if you have 110% confidence in your current and future PHP scripts.
    However, it’s recommended to restart scripts over time. Set the # of requests to a high number since the point is to avoid pm overhead. So for example at least pm.max_requests = 1000 …depending on your # of pm.max_children and # of requests per second."

    https://haydenjames.io/php-fpm-tuning-u ... rformance/

    Nun lasse ich es mit 80 und max processes 1000 laufen und denke dies ist sicherer.
    Kann man FPM in dieser Hinsicht genauer untersuchen? Mit einer Statuspage oder dergleichen.

  • Kann man FPM in dieser Hinsicht genauer untersuchen? Mit einer Statuspage oder dergleichen.

    Im Keyhelp Panel Benutzerverwaltung->Benutzer bearbeiten-> >_ PHP-FPM kann man unten eine Statusseite aktivieren.

    Vielleicht bringts was. Habe ich aber auch noch nie probiert.

  • Ich kann nun von einem weiteren Fortschritt berichten!!!


    Ich habe das LAPS Plugin (siehe oben) installiert und konnte im Admin sehen, dass z.B. bei der Seitenliste 7,4 Sekunden und >50MB auf ein Plugin entfallen, welches auf jeder Seite im Admin einmal gemacht wird.

    Nach Entfernung ging es runter von 8 Sekunden Wartezeit auf 0.6 Sekunden!

    Die Vorgangsweise mit dem Plugin ist top und hat sofort die Ursache gezeigt.

    --

    Konkret in meinem Fall: Es war ein Wordpress Updatecheck!

    Fazit: Verbesserte FPM Einstellungen und Profiling bringen die gewünschte Rootserver Performance zur Geltung.

  • Im Keyhelp Panel Benutzerverwaltung->Benutzer bearbeiten-> >_ PHP-FPM kann man unten eine Statusseite aktivieren.

    Vielleicht bringts was. Habe ich aber auch noch nie probiert.

    Das würde ich gerne verwenden, aber die Standard htaccess von WordPress overruled diese Statusseite und mir ist nicht klar, wohin ich umleiten müsste, um doch auf der FPM Statusseite zu landen.


    Obwohl der Fehler aktuell behoben ist gibt es noch eine Situation mit qtranslate bei der es gut wäre noch tiefer in die Ressourcen einzusteigen.

  • Die Statusseite für php-fpm muss man ja (glaube ich) auch erst aktivieren (Hier für 7.4.):


    /etc/php/7.4/fpm/pool.d/www.conf

    [www]

    pm.status_path = /woauchimmer


    Dann erhält man mit

    curl -L http:/localhost/woauchimmer

    einige Infos.


    Wenn man es sich direkt im Browser ansehen will, geht das auch. z.B. für Apache:

    /etc/apache2/apache2.conf

    <Location /woauchimmer>

    SetHandler "proxy:unix:/var/run/php/php7.4-fpm.sock|fcgi://localhost/woauchimmer"

    </Location>


    Ich habe mir dann dafür noch ein kleines Munin-Plugin gestrickt, das diese Werte abruft: :)

    pasted-from-clipboard.png


    Aber damit hat man auch "nur" einen Überblick. Welche Ursache eine Auslastung hat sieht man damit nicht.


    EDIT:

    Die Statusseite gibt es auch (undokumentiert) mit Live-Aktualisierung

    https://gist.github.com/Jiab77…0ab9bb3f17c5e33343da94fd8

    (Hier sollte man aber den Defaultnamen der Statusseite beibehalten und keinen eigenen wählen)

  • Die Statusseite gibt es auch (undokumentiert) mit Live-Aktualisierung

    https://gist.github.com/Jiab77…0ab9bb3f17c5e33343da94fd8

    (Hier sollte man aber den Defaultnamen der Statusseite beibehalten und keinen eigenen wählen)

    Dein Post ist Spitze!!


    Ich füge noch hinzu die Quick and Dirty Version, ohne etwas zu installieren:

    STATUS:

    Code
    service php$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')-fpm status


    Man erkennt damit auch schnell die Version, um einen Restart zu planen:


    Code
    systemctl restart php7.3-fpm.service


    Und kann dies dann verwenden, bzw. noch besser die universellere Variante:


    Code
    systemctl restart php$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')-fpm.service
  • Ein weiteres Problem, welches Laps gerade gezeigt hat.
    Wenn ich auf "Seite bearbeiten" gehe wird im Hintergrund der Wordpress Cronjob aufgerufen.
    Kurze Recherche.. das ist vollkommen unnötig es direkt beim Seitenaufruf zu machen: https://kinsta.com/knowledgebase/disable-wp-cron/

    Was der Cronjob macht ist z.B. Bestätigungsemails bei Woocommerce Bestellungen rausschicken.
    Habe ich also in das Crontab verschoben, dann ist es asynchron und beeinflusst die Performance der Seite nicht.

    Vorher: 7,2 Sekunden für den Aufbau des Formulars (Serverseitig)
    Nachher: 0,6 Sekunde

    Code
    In die wp-config.phpdefine('DISABLE_WP_CRON', true);


    Cronjob


    Code
    wget -q -O - https://DOMAIN.COM/wp-cron.php?doing_wp_cron >/dev/null 2>&1
  • Du könntest noch mit mysqltuner etwas mehr rausholen. Eventuell solltest du auch einen Wechsel auf MariaDB mit MyRocks in Betracht ziehen.


    NGINX compile ich übrigens mit PageSpeed.

    Damit holst du dann wirklich das letzte bisschen aus deiner Seite.

  • Du könntest noch mit mysqltuner etwas mehr rausholen. Eventuell solltest du auch einen Wechsel auf MariaDB mit MyRocks in Betracht ziehen.


    NGINX compile ich übrigens mit PageSpeed.

    Damit holst du dann wirklich das letzte bisschen aus deiner Seite.

    Diese 3 Ansätze klingen sehr interessant. Bis auf mysqltuner hatte ich diese vorher noch gar nicht auf dem Radar.
    Wenn MyRocks auf Debian 10 geht werde ich es auf jeden Fall probieren.

    Mysqltuner spuckt nach Verwendung des "Simple Installs" (https://github.com/major/MySQLTuner-perl) bereits einige Infos aus, um die Standard Keyhelp Installation zu verbessern.


    Und Neustart:

    Code
    service mysql restart
  • Ist das der RS 8000 G8 mit 2TB SAS Festplatte? Der RS 8000 G9 mit EPYC CPU und v.a. 2TB SSD bietet deutlich mehr fürs Geld, nämlich mehr CPU Power und insbesondere geringere Latenzen bei Zugriffen auf die HD. Und der G9 sollte auch noch weniger kosten als der G8. Wenn Du auf eine Sonderaktion warten kannst, gibts mitunter noch mehr Ressourcen (CPU Kerne) und/oder günstigere Preise.

    Besonders Datenbanken profitieren davon, wenn sie auf SSDs liegen, statt auf HDs.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

  • Ist das der RS 8000 G8 mit 2TB SAS Festplatte? Der RS 8000 G9 mit EPYC CPU und v.a. 2TB SSD bietet deutlich mehr fürs Geld, nämlich mehr CPU Power und insbesondere geringere Latenzen bei Zugriffen auf die HD. Und der G9 sollte auch noch weniger kosten als der G8. Wenn Du auf eine Sonderaktion warten kannst, gibts mitunter noch mehr Ressourcen (CPU Kerne) und/oder günstigere Preise.

    Besonders Datenbanken profitieren davon, wenn sie auf SSDs liegen, statt auf HDs.

    Danke. Für SSD macht es auf jeden Fall Sinn zu wechseln! Aber ist bereits SSD.

    Für Wechsel auf AMD würde ich aktuell nicht wechseln.


    Der Server mit 1TB Angebots-SSD, 64GB RAM und 8 Intelcores sollte bei eher geringen Besucherzahlen ein sehr gutes Ergebnis erzielen.