Wordpress-Shop/Woocommerce - Hoher DB-Traffic

[greystone]

Hallo zusammen,

ich habe hier einen Shop auf Wordpress/Woocommerce-Basis. (Ubuntu 18.04. / Aktuelles Wordpress).
Was mich etwas wundert, ist, dass der mit ca. 30 PHP-Requests(Benchmark mittels baton) pro Sekunde
eine 1 GBit Netzwerkverbindung zum DB-Server auslastet.

Irgendwie scheint mir das etwas viel zu sein.

Den Traffic habe ich mittels "nload" bzw. "dstat" auf der Konsole direkt während des Tests gemessen.

Was würdet Ihr dazu sagen?

Grüße,
g.

Anmerkung: Die Grösse der MySQL-DB(Dump) dahinter ist gerade mal 70 MB.

 

[GwenDragon]

Und? Sind das lokale Requests oder von Außen? Wenn letzteres, kann sein, dass jemand deine Datenbank, deinen Shop oder Wordpress knacken will.
Oder das Caching deines WP-Anwendung ist schlecht und irgendwelche randalierenden Bots fragen zu oft ab.

 

[marce]

Benchmark klingt danach, daß er sich einfach wundert, daß mit 30 Requests die DB mit 1GB/s angefragt wird -> er ist es selbst, kein Hackversuch.

... ich würde mal ein SQL-Log mitlaufen lassen und schauen, was da so ankommt. Woocomerce habe ich irgendwie unter "immer mal wieder komische Features / Verhalten / Bugs zwischendrin" gespeichert - oder es beißt sich was mit einem anderen Plugin. Im WP-Universum ist ja immer alles drin.

-> alles abschalten, testen, Plugin für Plugin zuschalten und schauen, ob sich was relevant ändert.

 

[greystone]

Benchmark klingt danach, daß er sich einfach wundert, daß mit 30 Requests die DB mit 1GB/s angefragt wird -> er ist es selbst, kein Hackversuch.

Vollkommen korrekt. Ich erzeuge mittels des Programmes "baton"(sowas wie ab(=apache benchmark)) viele parallele Requests.

-> alles abschalten, testen, Plugin für Plugin zuschalten und schauen, ob sich was relevant ändert.

Danke. Das werde ich mal tun.

 

[d4f]

Bei 30Req/s reden wir, nach Milchmädchenrechnung ohne Abrechnung von Header und Co, von ~ 4MB Datenbank-Daten pro HTTP-.Request.
Das kann bereits bei etwas schlecht optimiertem (oder erwartet cacheable aber nicht gecachetem) Datensatz passieren und ist nicht unbedingt anormal für das Ressourcenfresservieh Wordpress....
Spätestens wenn ein Plugin meint Joins/Sortierung oder Filterung client-seitig zu machen und der Datenbankserver alle Daten jeweils übertragen darf hat man schnell dieses Phänomen.

Neben Querylog finde ich auch zielführend das PHP-Modul xdebug mit welchem man einen Stacktrace des Prozessablaufs abspeichern kann. Als Beispiel für PHP mit .htaccess Kompatibilität (mod_php oder mod_litespeed) wäre die Syntax zur Aktivierung in Etwa:

php_value xdebug.profiler_output_name cachegrind.out.%u-%p-%R.trace
php_flag xdebug.profiler_enable 1
php_value xdebug.profiler_output_dir /absoluter/pfad/zum/Ordner/debug/