[Geschlossen] Hohe CPU-Auslastung durch WPML-Skripte
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Sun
Mon
Tue
Wed
Thu
Fri
Sat
-
-
9:00 – 18:00
9:00 – 18:00
9:00 – 18:00
9:00 – 18:00
9:00 – 18:00
-
-
-
-
-
-
-
Unterstützt die Zeitzone: America/Lima (GMT-05:00)
Hintergrund des Themas:
Ich versuche, die CPU-Auslastung auf unserer Website zu reduzieren, da WPML-Skripte eine hohe Belastung verursachen. Wir haben festgestellt, dass beim Aufruf der Shopseiten pro Seite zwischen 1000 und 2000 Datenbankabfragen erzeugt werden. Mit der Aktivierung von Redis konnten wir die Anfragen auf 150-200 reduzieren. Ein Test auf Staging mit deaktiviertem WPML zeigte eine deutliche Performance-Verbesserung. Link zur Seite, auf der das Problem zu sehen ist: versteckter Link
Die Symptome:
Hohe CPU-Auslastung durch WPML-Skripte, die eine extrem hohe CPU-Belastung verursachen. Die Anzahl der Datenbankabfragen liegt weit über dem Normalbereich.
Fragen:
Könnt ihr uns dabei helfen, die Ursache dieses Problems zu identifizieren?
Gibt es spezielle Einstellungen, die helfen könnten, die Skriptbelastung zu reduzieren?
Als Info: Ich habe dazu mal einiges recherchiert. Das scheint seit Jahren ein Problem bei WPML zu sein, da es immer wieder Forenthemen dazu gibt. Ich habe einige, von WPML vorgeschlagene, Lösungsansätze versucht, allerdings mit mäßigem Erfolg. Ich kann nicht sehen, dass sich dadurch maßgeblich etwas verändert hätte.
WPML benötigt in der Tat viel Leistung, weil es die Website in mehrere Sprachen übersetzten muss und sich die Inhalte dadurch duplizieren.
Die hier genannte hat 8 aktive Sprachen, soll bedeuten, es wenn WPML aktive ist muss das achtfache an Inhalten verwaltetet werden.
Eventuell wäre in diesem Fall Server-Upgrade (Mehr CPU und RAM) ratsam.
Ich kann hier anbieten einen Blick auf mögliche langsame Abfragen oder bestehende Fehler zu werfen, sollte das gewünscht sein.
Ich möchte einen temporären Zugriff (wp-admin und FTP) auf die Staging Site anfordern, um das Problem genauer zu untersuchen.
Die dafür erforderlichen Felder findst Du unterhalb des Kommentarbereichs, wenn Du dich anmelden, um die nächste Antwort zu hinterlassen. Die Informationen, die Du angibst sind privat, was bedeutet, dass nur Du und ich sie sehen und darauf zugreifen können.
WICHTIG
Lege bitte unbedingt eine Sicherungskopie der Website und der Datenbank an, bevor Du uns den Zugriff gewährst.
Wenn Du die Felder "wp-admin / FTP" nicht sehen kannst, werden Ihre Anmeldedaten für Post und Website als "PUBLIC" (Öffentlich) festgelegt. Veröffentliche die Daten NICHT, es sei denn, Du siehst die erforderlichen wp-admin / FTP-Felder.
Ich muss hier ggfls. ein Plugin namens "All In One WP Migration" installieren, um eine Kopie der Website anzulegen, auf welche ich das Problem genauer untersuchen kann.
Das private Antwortformular sieht folgendermaßen aus: versteckter Link
Klicke beim nächsten Antworten auf "I still need assistance".
Video: versteckter Link
Beachte bitte, dass wir verpflichtet sind, diese Informationen auf jedem Ticket individuell anzufordern. Wir dürfen nicht auf Zugangsinformationen zugreifen, die nicht speziell auf diesem Ticket im privaten Antwortformular übermittelt wurden.
1) Hier waren 17 Updates verfügbar, welche ich ausgeführt habe.
- WordPress 6.4.3 wird verwendet, aber die aktuelle Version lautet 6.6.2. Bitte aktualisiert WordPress.
- Das Storefront Parent Theme und die Plugins wurden ebenfalls aktualisiert.
2) Das Plugin "Query Monitor" wurde installiert, um Details zu vorhandenen PHP Fehlern oder langsamen Abfragen zu erhalten.
Da die Adminbar im Child Theme auf dem Frontend ausgeblendet wird, kann ich leider keine Informationen zu langsamen Abfragen auf dem Frontend einsehen. Im Backend werden mir keine angezeigt. Verwende ich das Storefront Theme erscheint auf dem Frontend eine langsame Abfrage mit einer Dauer von 0,39 Sekunden:
SELECT DISTINCT context COLLATE utf8mb4_bin
FROM wp_hxzgkfqtuc_icl_strings
Beim zweiten Laden der Seite wird diese nicht mehr angezeigt.
Hast Du weitere Beispiel zu langsamen Abfragen, die durch WPML verursacht werden?
3) Unter WooCommerce > WooCommerce Multilingual & Multicurrency > Status werden einige Konfigurationsprobleme angezeigt, die behoben werden sollte. Siehe Screenshot. Ich habe diese auf dem Staging bereits behoben.
Beispiele:
- Der Beitragstyp "Bestellungen (shop_order)" sollte in dem WPML Einstellungen immer als "Nicht übersetzbar" eingestellt sein.
- Die Taxonomie "Produkt-Kategorien (product_cat)" sollte immer als übersetzbar eingestellt sein.
- Die Produkt-Permalink-Basis sollte in alle Sprachen übersetzt werden (dies scheint auf der Website nicht wie erwartet zu funktionieren)
- Alle notwendigen WooCommerce-Seiten sollten angelegt und übersetzt sein
4) Installierte Plugins und Theme, die nicht mehr auf der Website verwendet werden, sollten gelöscht werden.
5) Siehe Tools > Site Health:
Automatisch geladene Optionen können die Leistung beeinflussen
Automatisch geladene Optionen sind Konfigurationseinstellungen für Plugins und Themes, welche bei jedem Seitenaufruf in WordPress automatisch geladen werden. Sind zu viele automatisch geladene Optionen vorhanden, können sie deine Website verlangsamen. Deine Website hat 1668 automatisch geladene Optionen (Größe: 4 MB) in der Optionstabelle, was dazu führen kann, dass deine Website langsam ist. Du kannst die Optionen, die von deiner Datenbank automatisch geladen werden, überprüfen und alle Optionen entfernen, die von deiner Website nicht mehr benötigt werden.
6) Hier wird ein Child Theme mit zahlreichen Anpassungen verwendet. Ich bitte darum, dass der Server-Admin einen Test mit aktiviertem Parent Theme ausführt, um auszuschließen, dass die Probleme nur dann auftreten, wenn das Child Theme verwendet wird.
7) Es sollte zudem gestestet werden, wie sich die Website verhält, wenn sie alleine mit WPML und unseren Addons auf dem Storefront Theme und keinen weiteren Plugin, bis auf WooCommerce, läuft.
Sollten die Probleme in diesem Setup nicht bestehen, muss man die zusätzlichen Plugins nach und nach aktivieren und jeweils weiter testen. Auf diese Weise sollte man feststellen können, welches Plugin in Verbindung mit WPML zu Problemen führt.
vielen Dank für deine Unterstützung und die detaillierten Vorschläge. Wir sind bereits seit Februar an diesem Thema dran und haben in der Zwischenzeit viele deiner Ansätze ausgearbeitet. Zudem haben wir mittlerweile einen noch leistungsfähigeren Server installiert.
Das Problem besteht jedoch weiterhin: Die WPML-Skripte verursachen immer noch etwa 90 % der Serverauslastung. Laut unserem Serveradministrator stammt diese Belastung eindeutig von WPML. Ich verstehe die Argumente, dass acht Sprachen aktiv sind und dies zu einer erhöhten Auslastung führt, aber eine derart hohe Belastung sollte dennoch nicht auftreten.
Darf ich dich daher bitten, einen tiefergehenden Blick darauf zu werfen, um das Problem an der Wurzel zu packen? Wir würden uns freuen, wenn du uns dabei helfen könntest, eine langfristige Lösung zu finden.
Ich habe hier leider keinen Einblick auf die CPU Auslastung und kann mich alleine auf langsame Abfragen und Ladezeiten beziehen.
Ich kann gerne anbieten eine lokale Kopie der Website auf einem virtuellen Server auf meinem lokalen Rechner zu installieren. Eventuell erhalte ich so mehr Details zur CPU-Auslastung. Mein PC läuft auf einem alten Ryzen5 Prozessor. Sollte dieser ebenfalls ausgelastete werden, dann erhalte ich eventuell einen Anhaltspunkt zum Testen.
Sollte sich das Problem aber mit meinem CPU nicht zeigen, dann kann die Ursache mit folgenden Punkten in Verbindung stehen:
1) Serverkonfiguration: Der Server könnte andere Ressourcenbeschränkungen, Konfigurationen oder Leistungsgrenzen haben als meine lokale Umgebung.
2) Traffic-Last: Die Website hat hohen Traffic oder gleichzeitige Nutzer, was zu einer höheren Ressourcennutzung führt.
3) Hosting-Umgebung: Unterschiede im Hosting (Shared vs. Dedicated) oder spezifische Servereinstellungen können die Leistung beeinflussen. Siehe Punkt 1)
Fragen:
Das Problem tritt auch auf dem Staging auf?
Ist das zudem die einzige Website, die auf diesem Server läuft?
Wärt ihr damit einverstanden, wenn ich eine lokale Kopie anlege?
vielen Dank für deinen Vorschlag, eine lokale Kopie anzulegen. Das klingt nach einer guten Idee und wir sind damit einverstanden.
Zu deinen Fragen:
Traffic-Last: Die Website hat in der Tat hohen Traffic, aber wir verfügen über sehr leistungsfähige Hardware, sodass viel Traffic und gleichzeitige Nutzer eigentlich kein Problem darstellen sollten.
Hosting-Umgebung: Derzeit nutzen wir Hetzner. Zuvor haben wir Raidbox getestet.
Fragen:
Das Problem tritt auch auf dem Staging auf?
Ja, das Problem haben wir auch auf dem Staging.
Ist das zudem die einzige Website, die auf diesem Server läuft?
Ja, es ist die einzige Website, die auf dem Server läuft.
Wir danken dir für deine Unterstützung und sind für jeden Hinweis sehr dankbar.
Das einzige "Problem", welches ich auf dem Staging aktuell sehen kann, sind 16 API-Aufrufe, die im Backend zu einer Ladezeit von 9-10 Sekunden führen.
Es scheint, als ob sich dieses Problem löst, sobald ich den Cache leere.
Die Homepage und deren Übersetzungen laden in 2-3 Sekunden komplett. Ich sehe hier kein direktes Problem.
Da ich die CPU-Auslastung des Stagings nicht sehen kann, bitte ich Euch folgende Tests durchzuführen.
WICHTIG:
Führe zunächst bitte alle Updates aus!
1) Deaktivieren alle zusätzlichen Plugins, die nichts mit WPML und unseren Add-Ons zu tun haben. Vergleiche nun die CPU-Auslastung.
2) Sollte das Problem verschwinden, beginne damit, die Plugins einzeln zu reaktivieren, oder aktivieren Sie sie in kleinen Gruppen. Überprüfe auf diese Weise, an welchen Stellen das Problem erneut auftritt, um das Plugin anzuzeigen, das das Problem verursacht.
3) Wenn dies die Ursache des Problems nicht geklärt hat, wechsle bitte zu einem Standardthema wie Twenty Twenty-One, um zu sehen, ob das Problem möglicherweise mit dem Thema zusammenhängt.
Sobald wir die Ursache identifizieren konnten, können wir dann versuchen das Problem zu replizieren und dann intern zu eskalieren. Ich stelle in diesem Fall eine Test-Site mir WPML zur Verfügung.
vielen Dank für deine Unterstützung bisher. Wir haben die Adminleiste im Staging nun aktiviert, und auch Query Monitor verwendet. Dieser funktioniert in der Regel auch ohne die Adminleiste, da er seine eigene Leiste hat.
Was den Vorschlag mit dem Standard-Theme angeht, ist uns bewusst, dass diese deutlich schneller laufen, da sie weniger Inhalte laden und weniger komplex sind. Um einen wirklich vergleichbaren 1:1-Test zu haben, müssten wir jedoch alle Assets und Funktionen aus unserem aktuellen Theme implementieren, was einiges an Aufwand bedeutet. Natürlich ist es klar, dass die Seite in einem simpleren Setup schneller läuft.
Ein großes Thema, das uns weiterhin beschäftigt, ist die immense Anzahl an Strings im System, die WPML erzeugt. Wir haben aktuell mehre 100.000 Strings in der Datenbank, was die Performance enorm belastet. Kannst du uns möglicherweise erklären, woher diese enorme Anzahl an Strings kommt und ob WPML selbst dafür verantwortlich ist? Gibt es hier eine Möglichkeit, diese zu reduzieren oder effizienter zu verwalten, ohne die Funktionalität der Seite einzuschränken?
Leider bringen uns die bisherigen Lösungsvorschläge nicht weiter, da die Skripte von WPML nachweislich die größte Last auf unserem System verursachen und enorm viel Performance fressen. Wir benötigen dringend eine langfristige und funktionierende Lösung für dieses Problem, da wir bereits an unsere Servergrenzen stoßen.
Gibt es von deiner Seite aus noch andere Ansätze, wie wir die Last dieser Skripte minimieren können?
Die String Translation Tabelle hatte mehr als 290.000 Einträge.
Ich habe unter WPML > Support > Fehlerbehebung folgende Option ausgeführt:
- String Labels bereinigen und optimieren
Des senkte die Anzahl der Datensätze auf der Tabelle auf etwa 36.000.
Ich habe danach mit folgender Abfrage alle Einträge, die bislang nicht übersetzt wurden, gelöscht.
DELETE FROM `<your-table-prefix>_icl_string_translations` WHERE `status` = '0';
Das <your-table-prefix> muss hier entsprechend ergänzt werden.
Die entfernte knapp 24.000 nicht übersetze Einträge aus der Tabelle.
Die icl_string_translations Tabelle hat nun nur noch knapp 15.000 Datensätze.
---
Was ich ebenso empfehlen würde, ist die Kollation auf allen Tabellen und der Datenbank selbst anzupassen. Die Datenbank, alle Tabellen und die betroffenen Spalten auf den Tabellen sollten utf8mb4_unicode_520_ci verwenden.
Bitte testet die CPU Auslastung nun erneut auf dem Staging und lasst mich wissen, ob sich etwas verändert hat.
Das Thema '[Geschlossen] Hohe CPU-Auslastung durch WPML-Skripte' ist für neue Antworten geschlossen.
