Table of Contents

WordPress Performance: Autoload verursacht hohen Traffic

Bei der Optimierung der WordPress Performance denkt man meist zuerst an schnellere Ladezeiten, einen leistungsfähigeren Server oder einen WordPress Cache, wie zB Redis. In komplexeren WooCommerce-Umgebungen kann die eigentliche Ursache jedoch an einer ganz anderen Stelle liegen. In diesem Praxisfall führte das Zuschalten eines zweiten Webservers zu massivem Netzwerk-Traffic zwischen PHP-FPM und MySQL. Verantwortlich waren Produktinformationen, die WordPress bei jeder Anfrage automatisch aus der Datenbank lud – obwohl sie für die jeweilige Anfrage gar nicht benötigt wurden.

Der Fall zeigt, warum man WordPress nicht allein anhand der Ladezeit im Browser optimieren sollte. Entscheidend ist das Zusammenspiel aus Webservern, PHP-FPM, Datenbank, Netzwerk und Anwendung.

Kurzfassung: Sobald der zweite Webserver aktiv war, stieg der interne Datenverkehr drastisch an. Mit iftop, tcpdump und Wireshark ließ sich der Traffic auf die Verbindung zwischen PHP-FPM und MySQL zurückführen. Die Analyse der übertragenen Daten zeigte ungewöhnlich große Autoload-Einträge in wp_options. Nach dem gezielten Deaktivieren von Autoload für nicht benötigte Plugin-Daten sank der Netzwerk-Traffic deutlich.

Ausgangslage: WooCommerce-Auktionen mit stark schwankender Last

Das System betreibt zeitkritische Auktionen auf Basis von WordPress und WooCommerce. Ein Hauptserver reicht während ungefähr 90 Prozent der Betriebszeit aus. In der Endphase großer Auktionen nimmt die Zahl der gleichzeitigen Zugriffe und Gebote jedoch stark zu. Für diese Lastspitzen wird automatisiert ein zweiter Webserver zugeschaltet. Ein Load-Balancer verteilt die eingehenden Anfragen anschließend auf beide Systeme.

Diese Architektur soll zwei Ziele erfüllen:

wirtschaftlicher Betrieb mit nur einem aktiven Hauptserver bei normaler Last,
zusätzliche Rechenleistung und Ausfallsicherheit während stark frequentierter Auktionsphasen.

Die Datenbank verblieb auf dem Hauptserver. Beide Webserver griffen somit auf dieselbe MySQL-Instanz zu. Dadurch blieben Gebote und Auktionsstände konsistent, unabhängig davon, welcher Webserver eine Anfrage bearbeitete.

Im Laufe der Zeit war der Datenbestand auf mehr als 16.000 Artikel angewachsen. Was mit einem kleineren Produktkatalog problemlos funktionierte, entwickelte sich dadurch schleichend zu einem ernsthaften Engpass.

Warum ein WordPress Cache nicht jedes Problem löst

Caching ist grundsätzlich ein wichtiger Bestandteil guter WordPress Performance. Ein Seiten- oder Objekt-Cache kann Datenbankzugriffe reduzieren und viele Seiten deutlich schneller ausliefern. Bei zeitkritischen Auktionen muss allerdings genau unterschieden werden, welche Daten zwischengespeichert werden dürfen.

Gebote, Auktionsstände und Verfügbarkeiten müssen unmittelbar aktuell sein. Veraltete Werte wären hier nicht nur störend, sondern könnten den korrekten Ablauf der Auktion beeinträchtigen. Deshalb wurde für diese dynamischen Daten bewusst kein zusätzlicher WordPress Cache wie Redis als vermeintliche Universallösung vorgeschaltet.

Das bedeutet nicht, dass Redis oder andere Caches für WooCommerce grundsätzlich ungeeignet wären. Statische Inhalte, Sitzungsdaten oder häufig gelesene, unkritische Objekte können durchaus davon profitieren. In diesem Fall wurde Redis lediglich als Session-Cache verwendet, damit der Load-Balancer Anfragen eines Users problemlos auf beide Webserver weiterleiten konnte und kein IP-Pinning notwendig war. Ein Cache beseitigt jedoch nicht die Ursache, wenn WordPress bei nahezu jeder Anfrage große, nicht benötigte Datenmengen lädt. Er kann das Problem sogar verdecken oder lediglich an eine andere Stelle verschieben.

Das Symptom: extremer Netzwerk-Traffic nach dem Skalieren

Sobald der zweite Webserver zugeschaltet wurde, stieg der Netzwerk-Traffic zwischen Haupt- und Zweitserver auffällig stark an. Die übertragene Datenmenge war viel zu groß, um allein durch den normalen Web-Traffic zwischen Load-Balancer und Webserver erklärt werden zu können.

Besonders kritisch wurde die Situation beim Erreichen des AWS-Traffic- beziehungsweise I/O-Limits der eingesetzten Instanz. Wurde der Netzwerkdurchsatz gedrosselt, verlangsamte sich nicht nur der zweite Server. Da Datenbankabfragen und PHP-Prozesse aufeinander warteten, reagierte der gesamte Dienst zunehmend träge.

Die ersten deutlichen Hinweise lieferte das Grafana-Dashboard. Während CPU- und Speicherauslastung allein die Ursache nicht eindeutig erkennen ließen, war die ungewöhnlich hohe Netzwerklast unmittelbar sichtbar.

Schritt 1: Netzwerkverbindungen mit iftop eingrenzen

Der erste Analyseschritt erfolgte mit iftop. Das Werkzeug zeigt in Echtzeit, zwischen welchen Systemen und Ports Daten übertragen werden. Dadurch ließ sich erkennen, dass ein erheblicher Teil des Traffics zwischen PHP-FPM auf dem Zweitserver und MySQL auf dem Hauptserver entstand.

Ein typischer Aufruf lautet:

sudo iftop -n -P -i eth0

Die Parameter bewirken:

-n: keine DNS-Auflösung, damit die Anzeige schneller und eindeutiger bleibt,
-P: Anzeige der verwendeten Ports,
-i eth0: Überwachung der angegebenen Netzwerkschnittstelle.

Damit war die Richtung der Analyse klarer: Die PHP-Anwendung forderte große Datenmengen von MySQL an. Andere mögliche Quellen konnten zu diesem Zeitpunkt aber noch nicht vollständig ausgeschlossen werden.

Schritt 2: Warum SHOW PROCESSLIST nicht ausreichte

Mit MySQL lässt sich über SHOW FULL PROCESSLIST prüfen, welche Abfragen gerade ausgeführt werden:

SHOW FULL PROCESSLIST;

Die Abfragen in diesem Fall waren jedoch sehr kurzlebig. Bis die Prozessliste angezeigt wurde, waren viele davon bereits beendet. Einzelne Momentaufnahmen lieferten deshalb keinen eindeutigen Hinweis darauf, welche Abfragen die großen Datenmengen verursachten.

Für die weitere Analyse gab es zwei sinnvolle Möglichkeiten:

Alle relevanten Abfragen über das MySQL General Query Log beziehungsweise eine gezielte Protokollierung erfassen und anschließend reproduzieren.
Den tatsächlichen Netzwerkverkehr mit tcpdump mitschneiden und in Wireshark untersuchen.

Das Query Logging hätte die SQL-Anweisungen sichtbar gemacht. Es hätte aber nicht automatisch gezeigt, wie viele Daten MySQL tatsächlich an PHP-FPM überträgt. Außerdem bestand noch die Möglichkeit, dass neben der Datenbankverbindung weitere Netzwerkquellen beteiligt waren. Deshalb fiel die Entscheidung auf die zweite Variante.

Hinweis: Das MySQL General Query Log kann auf produktiven Systemen zusätzlichen Speicherbedarf und Last verursachen. Es sollte nur gezielt, möglichst kurzzeitig und mit ausreichend freiem Speicherplatz aktiviert werden.

Schritt 3: Traffic mit tcpdump aufzeichnen

Auf dem Zweitserver wurde der Verkehr zum Datenbankserver und zum MySQL-Port 3306 aufgezeichnet. Ein vereinfachtes Beispiel:

sudo tcpdump -i eth0 -nn -s 0 \
  host 172.31.0.226 and port 3306 \
  -w wordpress-mysql-traffic.pcap

Dabei steht:

-nn für die numerische Ausgabe von Adressen und Ports,
-s 0 für das vollständige Erfassen der Pakete,
host ... and port 3306 für die Begrenzung auf die relevante Datenbankverbindung,
-w für das Speichern im PCAP-Format.

Da eine PCAP-Datei Anwendungsdaten und damit unter Umständen sensible Informationen enthalten kann, muss sie wie ein Datenbankauszug geschützt, sicher übertragen und nach Abschluss der Analyse gelöscht oder sicher archiviert werden.

Schritt 4: MySQL-Datenströme in Wireshark analysieren

Die PCAP-Datei wurde anschließend in Wireshark geöffnet. Durch das Filtern und Nachverfolgen einzelner TCP-Verbindungen ließ sich der Inhalt zusammengehöriger Datenströme untersuchen.

Das ist nur möglich, wenn die MySQL-Verbindung nicht per TLS verschlüsselt ist oder die für eine Entschlüsselung erforderlichen Sitzungsdaten vorliegen. Bei verschlüsselten Datenbankverbindungen bleiben Verbindungsrichtung, Datenmenge und zeitlicher Verlauf sichtbar, nicht jedoch die übertragenen SQL- und Nutzdaten im Klartext.

Die Analyse bestätigte zunächst die Vermutung aus iftop: Der größte Teil des zusätzlichen Traffics entstand tatsächlich zwischen PHP-FPM und MySQL. Entscheidend war jedoch der Inhalt der Antworten. MySQL übertrug große Mengen an Produkt- und Auktionsinformationen, obwohl diese für die bearbeiteten Anfragen nicht benötigt wurden.

Damit war das Problem nicht in erster Linie ein langsames Netzwerk und auch keine einzelne besonders lange SQL-Abfrage. Viele schnelle Abfragen können ebenfalls eine schlechte WordPress Performance verursachen, wenn jede davon eine große Ergebnismenge über das Netzwerk transportiert.

Die Ursache: zu viele automatisch geladene WordPress-Optionen

Die weitere Untersuchung führte zur Tabelle wp_options. WordPress speichert dort zentrale Einstellungen von WordPress selbst, Themes und Plugins. Einträge mit aktivem autoload werden gebündelt bei Seitenaufrufen geladen. Das ist für kleine, häufig benötigte Einstellungen effizient. Werden dort jedoch große oder sehr viele selten benötigte Daten abgelegt, wächst die bei jeder Anfrage geladene Datenmenge erheblich.

In diesem Fall hatte ein Auktions-Plugin umfangreiche Produkt- beziehungsweise Gebotsinformationen als automatisch zu ladende Optionen gespeichert. Mit dem Wachstum auf mehr als 16.000 Artikel war die Gesamtmenge auf rund 45 MB angewachsen.

Auf einem einzelnen Server kann ein Teil dieses Problems zunächst unauffällig bleiben, weil die Verbindung zwischen PHP und MySQL lokal erfolgt. Beim zweiten Webserver musste MySQL diese Daten jedoch über das Netzwerk übertragen. Wenn mehrere PHP-FPM-Prozesse gleichzeitig Anfragen bearbeiteten, vervielfachte sich die Datenmenge entsprechend.

Ein vereinfachtes Rechenbeispiel verdeutlicht die Größenordnung:

45 MB Autoload-Daten × 50 PHP-Anfragen = 2.250 MB

Das ist keine exakte Messung des Netzwerkverkehrs, weil Wiederverwendung innerhalb eines PHP-Prozesses, Protokoll-Overhead und konkrete Request-Abläufe berücksichtigt werden müssen. Es zeigt aber, warum selbst kurze Datenbankabfragen einen enormen Durchsatz erzeugen können.

WordPress weist selbst darauf hin, dass große, nicht verwendete Autoload-Daten die Performance beeinträchtigen. Seit WordPress 6.6 existieren neben den älteren Werten yes und no auch Werte wie on, off, auto, auto-on und auto-off. Eigene SQL-Abfragen sollten diese Varianten berücksichtigen.

Autoload-Daten mit WP-CLI prüfen

Wer WordPress optimieren möchte, kann die Gesamtgröße der automatisch geladenen Optionen zunächst mit WP-CLI ermitteln:

wp option list --autoload=on --format=total_bytes

Die größten Autoload-Einträge lassen sich beispielsweise so anzeigen:

wp option list --autoload=on \
  --fields=option_name,size_bytes | sort -n -k 2 | tail -30

Für eine gruppierte Auswertung direkt in MySQL kann wp db query verwendet werden. Das Tabellenpräfix wird dabei dynamisch ermittelt:

wp db query "
SELECT
    autoload,
    COUNT(*) AS anzahl,
    ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS groesse_mb
FROM $(wp db prefix)options
GROUP BY autoload
ORDER BY SUM(LENGTH(option_value)) DESC;
"

Anschließend können verdächtige Plugin-Einträge gezielt untersucht werden:

wp db query "
SELECT
    option_name,
    autoload,
    ROUND(LENGTH(option_value) / 1024, 2) AS groesse_kb
FROM $(wp db prefix)options
WHERE option_name LIKE 'yith_wcact_update_list_bids_%'
ORDER BY LENGTH(option_value) DESC
LIMIT 30;
"

Autoload gezielt deaktivieren – nicht pauschal löschen

Die betroffenen Optionen wurden nicht gelöscht. Stattdessen wurde lediglich verhindert, dass WordPress sie bei praktisch jeder Anfrage automatisch lädt. Wenn das Plugin einen Wert tatsächlich benötigt, kann es ihn weiterhin gezielt aus der Datenbank abrufen.

Vor Änderungen an wp_options sind mindestens ein aktuelles Datenbank-Backup, eine dokumentierte Auswahl der betroffenen Einträge und nach Möglichkeit ein Test in einer Staging-Umgebung erforderlich:

wp db export before-autoload-change.sql

Danach kann Autoload für das zuvor geprüfte Namensmuster deaktiviert werden:

wp db query "
UPDATE $(wp db prefix)options
SET autoload = 'off'
WHERE option_name LIKE 'yith_wcact_update_list_bids_%'
  AND autoload IN ('yes', 'on', 'auto-on', 'auto');
"

Wichtig ist, nicht wahllos alle Autoload-Einträge abzuschalten. Manche Optionen werden tatsächlich bei nahezu jedem Seitenaufruf benötigt. Eine pauschale Änderung kann dann zusätzliche Einzelabfragen verursachen oder Funktionen beeinträchtigen.

Für einen exakten Rollback sollten die ursprünglichen autoload-Werte je option_name vor der Änderung exportiert werden. Das bloße Zurücksetzen aller betroffenen Zeilen auf einen einheitlichen Wert wäre ungenau, falls vorher unterschiedliche Werte vorhanden waren.

Nach der Änderung wurden insbesondere folgende Funktionen geprüft:

Darstellung laufender und beendeter Auktionen,
Abgabe und Speicherung neuer Gebote,
Aktualisierung des aktuellen Höchstgebots,
Produktlisten und Produktdetailseiten,
Hintergrundprozesse und geplante Aufgaben,
Verhalten mit einem und mit zwei aktiven Webservern.

Das Ergebnis: deutlich weniger Traffic und stabile Skalierung

Nach dem Deaktivieren von Autoload für die nicht bei jeder Anfrage benötigten Plugin-Daten sank der Traffic zwischen dem zweiten Webserver und dem zentralen MySQL-Server drastisch. Der zusätzliche Server konnte wieder zugeschaltet werden, ohne das Netzwerk-I/O-Limit zu erreichen oder den gesamten Dienst auszubremsen.

Die Verbesserung war unmittelbar im Grafana-Dashboard sichtbar. Besonders aussagekräftig war dabei der direkte Vergleich vor und nach der Änderung unter vergleichbarer Last.

[BILDPLATZHALTER 7: Gegenüberstellung der Grafana-Netzwerklast vor und nach der Autoload-Optimierung]

Empfohlener Alternativtext: „WordPress Performance vor und nach der Optimierung der Autoload-Daten“

Was dieser Fall über WordPress Performance zeigt

Der konkrete Fehler lag in der Anwendungsebene, sichtbar wurde er aber zunächst als Netzwerkproblem. Genau das macht die systematische Analyse von WordPress- und WooCommerce-Systemen anspruchsvoll.

Aus dem Vorfall lassen sich mehrere allgemeine Erkenntnisse ableiten:

1. Skalierung kann verborgene Probleme sichtbar machen

Ein zweiter Webserver erzeugt nicht automatisch eine bessere WordPress Performance. Wenn jeder Server unnötig große Datenmengen von einer zentralen Datenbank abruft, kann horizontale Skalierung den Engpass sogar verstärken.

2. Kurze Queries sind nicht automatisch harmlose Queries

SHOW PROCESSLIST zeigt vor allem gerade aktive Abfragen. Eine Abfrage kann sehr schnell abgeschlossen sein und trotzdem viele Megabyte übertragen. Neben der Laufzeit müssen deshalb auch Ergebnismenge, Häufigkeit und Netzwerkdurchsatz berücksichtigt werden.

3. Ein WordPress Cache ist kein Ersatz für Ursachenanalyse

Caching kann ein gut aufgebautes System erheblich beschleunigen. Werden bei jeder Anfrage unnötige Daten geladen, sollte jedoch zuerst die Ursache beseitigt werden. Bei zeitkritischen Daten muss außerdem verhindert werden, dass veraltete Informationen ausgeliefert werden.

4. Datenwachstum verändert das Verhalten eines Systems

Eine Konfiguration, die bei einigen hundert Produkten problemlos funktioniert, kann bei mehr als 16.000 Artikeln völlig andere Auswirkungen haben. Deshalb sollten Datenmenge und Autoload-Größe kontinuierlich überwacht werden.

5. Metriken verschiedener Ebenen müssen zusammengeführt werden

Grafana zeigte die Auffälligkeit, iftop identifizierte die Verbindung, tcpdump erfasste den Datenverkehr und Wireshark machte den Inhalt sichtbar. Erst die Kombination dieser Werkzeuge führte zuverlässig zur Ursache.

WordPress optimieren: eine kurze Prüfliste für ähnliche Fälle

Wenn ein WordPress- oder WooCommerce-System unter Last langsam wird, empfiehlt sich folgende Reihenfolge:

Zeitpunkt und Ausmaß des Problems in Grafana oder einem vergleichbaren Monitoring-System bestimmen.
CPU, Arbeitsspeicher, I/O-Wartezeit und Netzwerkdurchsatz gemeinsam betrachten.
Mit iftop oder einem ähnlichen Werkzeug die wichtigsten Kommunikationsbeziehungen identifizieren.
MySQL-Abfragen, Häufigkeiten und übertragene Ergebnismengen untersuchen.
Die Größe der WordPress-Autoload-Daten kontrollieren.
Verdächtige Plugin-Optionen fachlich prüfen, bevor Autoload geändert wird.
Vor Änderungen ein Backup und eine Rückfallmöglichkeit vorbereiten.
Änderungen unter realistischer Last mit allen kritischen Geschäftsprozessen testen.
Vorher-Nachher-Werte dokumentieren.
Grenzwerte und Alarmierungen an die gewonnenen Erkenntnisse anpassen.

Fazit

Wer die WordPress Performance nachhaltig verbessern will, sollte nicht vorschnell nur Plugins installieren, Hardware vergrößern oder einen WordPress Cache aktivieren. In diesem Fall lag der entscheidende Engpass in automatisch geladenen Plugin-Daten, die mit jedem Request zwischen MySQL und dem zweiten Webserver übertragen wurden.

Durch die Kombination aus Monitoring, iftop, tcpdump, Wireshark und gezielten WP-CLI-Abfragen konnte die Ursache eindeutig nachgewiesen werden. Nach der kontrollierten Änderung der Autoload-Einstellungen sank der Netzwerk-Traffic deutlich und die automatische Skalierung funktionierte wieder wie vorgesehen.

Gerade bei geschäftskritischen WooCommerce-Systemen ist das der entscheidende Unterschied zwischen bloßem Ausprobieren und systematischer Performance-Analyse.

Unterstützung bei WordPress-Performance-Problemen

Ihre WordPress- oder WooCommerce-Installation wird unter Last langsam, erreicht regelmäßig ihre Servergrenzen oder zeigt unerklärliche Lastspitzen? Zanteres analysiert die gesamte Verarbeitungskette – vom Load-Balancer über nginx, PHP-FPM und MySQL bis zur WordPress-Anwendung – und beseitigt Engpässe gezielt.

Jetzt unverbindlich eine WordPress-Performance-Analyse anfragen.

Weiterführende technische Informationen

Brauchen Sie Hilfe oder Unterstützung bei Performance-Problemen mit Ihrer WordPress-Seite? Dann kontaktieren Sie uns!