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 beantwortet Anfragen im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.

Our next available supporter will start replying to tickets in about 6.02 hours from now. Thank you for your understanding.

Schlagwörter: 

This topic contains 7 Antworten, has 2 Teilnehmer.

Last updated by lydiaP vor 1 Jahr.

Assigned support staff: Cristina.

Autor Beiträge
September 18, 2018 um 8:34 am

lydiaP

Ich versuche:
Wir haben vor kurzem eine Performance Optimierung an unserer Website durchgeführt. Beim Testen haben wir festgestellt, dass WPML das System ausbremst, sehen aber nicht genau, warum. Kann es an den nicht verknüpften Post-Übersetzungen im Bereich "Aktuell" liegen? Wir hatten schon einmal einen Supportthread dazu mit Cristina. Wie können wir WPML so optimieren, dass unsere Website Performance wieder tolerabel wird? Danke :).

URL der/meiner Website, auf der das Problem auftritt:
hidden link

Erwartet hatte ich zu sehen:
Schnelle Ladezeiten wie früher vor den letzten Updates (vor ca. 4 Monaten)

Stattdessen bekam ich:
Langsame Ladezeiten und das Feedback, dass es an WPML liegt.

September 18, 2018 um 6:20 pm #2746220

Cristina

Hallo Lydia,

vielen Dank für die Infos.

Generell ist die Performance im Backend bei Nutzung von WPML immer etwas langsamer, aber das betrifft in der Regel nur das Backend.

Hier müsste man genau sehen, ob die Performance nur das Backend betrifft und inwieweit man das bezüglich WPML optimieren kann, oder ob die Probleme im Frontend auftreten.

Bei langsamen Ladezeiten im Frontend ist es oft ein ganze Kombination an Faktoren, die gar nichts mit WPML zu tun haben. Das kann man mit Tools wie tools.pingdom.com testen, bei denen die Komponenten erfasst werden, die bei der Ladezeit bremsen.

Faktoren von WPML im Backend können die Scanvorgänge im Hintergrund sein, sowie die Anzahl an verfügbaren Variablen und die Speicherkapazität.

Um die Performance im Backend zu verbessern, sind Arbeitsspeicher und Anzahl der maximalen Variablen die effektivsten Mittel, um schneller zu speichern und Seite zu verarbeiten

Der aktuelle Wert maxinputvars ist mit 1000 eher wenig. Wenn Sie hier den Wert auf 3000 oder mehr erhöhen, werden Sie mögliche Flaschenhälse beim Speichern und Übersetzen von komplexen oder längeren Seiten vermeiden, oder bei Kategorieseiten mit vielen Variablen in der Zweitsprache.

Diesen Wert können Sie in den PHP Einstellungen erhöhen (Datei php.ini).

Auch eine Umstellung auf PHP 7 oder höher kann die Performance positiv beeinflussen.

WPML arbeitet zwar noch mit PHP 5.6 und MySQL 5.5, aber schon für WordPress ist es eigentlich optimal, etwas neuere Versionen zu nutzen. SQL kann man nicht ohne weiteres updaten, aber PHP kann man in der Regel problemlos auf Version 7 oder höher setzen.

Auch der PHP Speicher kann hier einen Rolle spielen. 256M sind eventuell wenig, wenn viele rechenintensive Plugins und Themefunktionen gleichzeitig arbeiten.

Wenn Sie mehr Speicher auf Ihrem Hosting einsetzen können, sind höhere Werte sicher besser.

Wenn die Ausbremsung neu und im Vergleich zu früher sehr auffällig ist, kann es sich auch um einen Konflikt zwischen Komponenten handeln, bei dem die Seiten irgendwo ausgebremst werden, weil etwas nicht richtig lädt.

Für den Fall, dass es so ein Problem auf der Seite gibt, der für eine zusätzliche Verzögerung sorgt, wäre es hilfreich, wenn Sie uns die Informationen des WordPress Debugs zukommen lassen könnten. Das sind die Fehlermeldungen im WordPress selbst, nicht die von WPML.

Dafür müssten Sie in der Datei wp-config.php im Root-Verzeichnis der WordPress-Installation diese Zeile suchen:

define('WP_DEBUG', false);

Bitte ändern Sie dort "false" auf "true" und fügen Sie eine weitere Zeile ein, so dass es wie folgt lautet:

[php]
define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY',false);

Damit werden die PHP-Fehler von WordPress in eine Datei namens debug.log im Verzeichnis /wp-content/ gespeichert.

Es handelt sich um eine Textdatei, die nur dann entsteht, wenn es PHP-Fehler auf der Seite gibt. Diese Fehler können wir über den Link kopieren und analysieren können.

Wenn Sie wollen, kann ich das auch selbst ändern, aber dann sollten Sie bitte vorab einen funktionierenden Backup erstellen, falls etwas schief läuft.

Ich kann parallel dazu das Duplikat installieren und auf einem Testserver checken, um die Werte zu vergleichen.

Hier haben wir auch etwas Dokumentation zum Thema:
https://wpml.org/2012/01/can-your-site-run-faster/
https://wpml.org/faq/why-string-translation-appears-to-slow-down-sites/

Vielen Dank und schönen Gruß,
Cristina

September 25, 2018 um 3:38 pm #2764578

lydiaP

Hallo Cristina

Vielen Dank für Ihre ausführlich Antwort. Das sind ganz schön viele Infos, wäre super, wenn Sie mir noch etwas weiter helfen könnten (bin etwas überfordert mit den ganzen Php-Sachen ehrlich gesagt).

Wir konnten das Frontend durch den Wechsel des Caching Plugins und ein paar Einstellungen nun schon etwas beschleunigen. Aber es ist noch deutlich Luft nach oben, besonders bei den Backend-Ladezeiten.

Hier habe ich noch Rückfragen:

(1) "maxinputvars: Diesen Wert können Sie in den PHP Einstellungen erhöhen (Datei php.ini)":

Wo finde ich diese Datei php.ini im Verzeichnis "wp"? Ich finde nur user.ini und index.php.

(2) "… aber PHP kann man in der Regel problemlos auf Version 7 oder höher setzen.":

Wo kann ich die Php-Version einstellen?

(3) "Auch der PHP Speicher kann hier einen Rolle spielen. 256M sind eventuell wenig, … Wenn Sie mehr Speicher auf Ihrem Hosting einsetzen können, ":

Wo kann ich den Php-Speicher im erhöhen? Im Hosting/c-panel?

(4) "WordPress Debugs zukommen lassen… Wenn Sie wollen, kann ich das auch selbst ändern, aber dann sollten Sie bitte vorab einen funktionierenden Backup erstellen":

Gerne würde ich auf Ihr Angebot zurückkommen, dass Sie die debug Datei erstellen könnten. Wir sichern unsere Site jeden Tag mit Updraft Plus. Falls Sie das Backup brauchen, kann ich Ihnen gern den aktuellen Dropbox-Link zusenden. Die Login-Informationen für WP und FTP habe ich oben als private message in meinen ersten Beitrag geschrieben.

Wäre es möglich, dass Sie sich das mal anschauen könnten?

Vielen Dank
Lydia

September 27, 2018 um 10:29 am #2770094

Cristina

Hallo Lydia,

vielen Dank für das Feedback und entschuldigen Sie die späte Antwort.

Zu Ihren Fragen:

Die PHP bezogenen Werte werden im Hostingpanel eingestellt, weil das variable Werte im PHP sind, die ausserhalb der WordPress Installation definiert werden.

PHP ist die Programmiersprache, in der WordPress gesteuert wird. Diese Sprache wird von dem Server bereitgestellt, bzw. von dem Hostinganbieter.

Daher werden diese Einstellungen meist im Control Panel des Server eingestellt.
Wie und wo genau das dann konfiguriert wird, hängt von dem jeweiligen Hosting-Service ab.

In der Regel gibt es dort eine Art Formular für die PHP-Einstellungen.

Oder alternativ eine Zugang zu einer Datei php.ini, in der die Einstellungen für eine konkrete Installation/Domain/Webseite erfasst werden.

Dort kann man dann die PHP Version wählen, den PHP Speicher definieren und die Anzahl der verfügbaren Variablen einstellen.

Wenn Sie keinen direkten Zugriff darauf haben, kann das auch der Hosting-Service für Sie erledigen, denn das sind Einstellungen, die nicht mehr mit dem WordPress zu tun haben.

Ich habe gesehen, dass die Einrichtung des WordPress etwas komplexer ist als gewöhnlich: Das WordPress ist in einem Unterordner installiert, und die Konfigurationsdatei wp-config.php enthält nur einige der üblichen Konfigurationen, der Rest wird von einer übergeordneten Instanz gesteuert.

Das kann eventuell zu längeren Wartezeiten führen, bis alle Elemente einer Seite abgerufen werden.

Um zu testen, was WPML hier zu einem langsamen Seitenaufbau beiträgt, habe ich den Backup von gestern heruntergeladen, damit ich die einzelnen Komponente messen kann und eventuell mit der Life-Seite vergleichen kann.

Ich habe auch den Debug-Log aktiviert, aber es werden keine PHP Fehler registriert. Das ist eigentlich ein gutes Zeichen.

Ich melde mich, sobald ich etwas mehr Informationen habe.

MfG
Cristina

Oktober 2, 2018 um 8:57 am #2780727

lydiaP

Hallo Cristina

Vielen Dank für Ihre Antwort und für Ihre Hilfe. Ich habe Ihre Inputs bezüglich Php-Einstellungen nun versucht umzusetzen:

(1) maxinputvars auf "3000" hochgesetzt.
(2) php-Speicher auf 512M hochgesetzt. Dieser war durch eine Regel vorher auf 128M gesetzt. Das habe ich gelöscht und durch eine neue Regel "memory_limit" "512M" ersetzt.
(3) Mit Hosting Anbieter Php-Version überprüft: Laut Hosting-Anbieter läuft die Website bereits unter PHP 7.2. Deshalb habe ich diese Einstellung nicht geändert.

Eine Frage hätte ich noch zu Punkt (2):
Diese Einstellung heisst in unseren Hosting Einstellungen "memory_limit" ist das richtig?

Ich habe Screenshots beigefügt, wo ich das im Hosting geändert habe. Wäre super, wenn Sie kurz einen Blick darauf werfen könnten, und mir bestätigen könnten, dass ich Ihr Feedback richtig umgesetzt habe. Vielen Dank.

Und noch eine letzte Frage für heute:
Konnten Sie bereits mehr Informationen über das Backup und den Debug-Log herausfinden?

Vielen Dank nochmals für Ihre Hilfe und ich würde mich freue, nochmals von Ihnen zu hören.

Beste Grüsse
Lydia

Oktober 2, 2018 um 10:34 am #2781120

Cristina

Hallo Lydia,

vielen Dank für die Infos, soweit ich sehe, sieht im Panel alles korrekt aus.

Sie werden jetzt schon eine beträchtliche Verbesserung gegenüber der Version vor einigen Tagen bemerkt haben. Ich habe die Seiten mit externen Browsern besucht und die englischen Artikel haben alle gut und schnell geladen. Die Index-Seiten mit vielen Modulen sind ein wenig langsamer, aber aus Nutzersicht ok.

Im Debug-Log meiner Testseite wurde fehlender Speicher angezeigt, aber das hat sich jetzt ja wohl erledigt.

Geschwindigkeit aus Nutzersicht:

Um das objektiver zu testen, sollte man die reale Seitengeschwindigkeit messen, die ganz anders als die Backend-Geschwindigkeit sein kann.

Um die realen Ladezeiten zu messen, kann man externe Tools nutzen. Damit wird die Situation aus der Ferne gemessen.

Mit diesen kostenlosen Werkzeugen können Sie testen, wie die Ladezeiten für externe Besucher sind. Das hat den Vorteil, dass diese Tools keine verfälschte Sicht bieten, wie zb. der eigene Browser oder die eigene Seite, wenn man dort eingeloggt ist:

hidden link
hidden link
hidden link
hidden link
hidden link
hidden link

Beispielsweise wurde für die Seite hidden link eine Ladezeit von 536 Millisekunden gemessen, (hidden link), was sehr gut ist.

Wenn Sie hier ein wenig testen, sehen, Sie, dass die einzelnen Artikel schnell laden.

Wenn es aber Seiten mit vielen Inhalten sind, wie beispielsweise Index-Seiten wie hidden link werden diese Seiten langsamer laden.

Das liegt daran, dass hier viele Komponenten geladen werden. Wenn Sie diese Seite mit beispielsweise mit hidden link analysieren, sehen Sie, dass die Seite 3 Sekunden braucht.

Das ist aber eigentlich noch innerhalb des Akzeptablen bei Seiten mit vielen Bildern. Wenn Sie die Informationen ansehen, gibt es viele Dinge die eine Rolle spielen, wobei WPML nur für einen kleinen Teil der Verzögerungen verantwortlich ist. Je mehr Elemente eine Seite von der Datenbank abruft (Bilder, Stilvorlagen, Texte), desto mehr Hin-und Her gibt es zwischen Browser und Server. Was vom Cache abgefangen bzw. ausgeliefert wird, ist Netto-Ersparnis.

Bei einzelnen Tipps und Artikeln wird das also immer schneller gehen, als bei dynamischeren Seiten, in denen Inhalte von vielen Stellen abgerufen werden.

Idealerweise würde man hier die unterschiedlichen Ladezeiten mit und ohne WPML messen, damit man sieht, wieviel zusätzliche Zeit eventuell von WPML hinzugekommen ist, oder ob die Seiten an sich schon irgendwo etwas hakeln.

Geschwindigkeit im Backend:

Bei der Verwendung von Query Monitor sollten Sie auch im Auge behalten, dass hier im Backend gemessen wird.

Die Anzahl der Queries und ihre Zeiten sind dabei nicht die gleichen wie bei dem Aufruf einer Seite durch einen Nutzer.

Sie haben im WP-Rocket Cache jetzt z.b. den Cache für eingeloggte Nutzer eingestellt. Das kann das Backend beschleunigen, es kann aber auch zur Anzeige von gecachten Inhalten führen, die Sie bedenken müssen, wenn mal etwas nicht sofort so erscheint, wie Sie es gerade gespeichert haben.

Query Monitor selbst nutzt auch vielen Ressourcen, so dass ein etwas langsames Backend bei dem Aufruf und Nutzung einer Seite mit Query Monitor zu erwarten sind. Diese Plugin protokolliert die Anfragen zwischen Backend und Datenbank. Dabei gibt es natürlich viele WPML-Anfragen und Anfragen mit viel Datenvolumen. Das sind aber nicht die gleichen Anfragen, wie ein externer Nutzer der Webseite bekommt. Daher kann hier schnell der Eindruck entstehen, die langsame Zeit käme vorwiegend von WPML.

Was Sie jetzt noch in WPML optimieren können ist diese Einstellung:

In WPML > String Translation gibt es unten auf der Seite eine Metabox, in der die Einstellung aktiviert ist "Finden Sie heraus, wo auf der Seite Strings auftauchen". Wenn Sie das Häkchen hier entfernen, wird das Backend etwas flotter. Diese Einstellung ist nur notwendig, wenn man herausfinden will, wo genau im Code ein bestimmter Texte auftaucht. Das ist aber auf der Live-Seite nicht mehr notwendig.

Eine zweite kleine Besserung können Sie mit Hilfe der Fehlerbehebungsseite in WPML >Support erreichten.

Wenn Sie hier den Button "ST-DB-Cache-Tabellen wieder erstellen" nutzen, wird die Tabelle mit den gecachten Strings geleert. Da diese Tabelle mit der Zeit ziemlich wächst, kann das helfen, die Datenbank etwas zu verschlanken.

Mfg,
Cristina

Oktober 3, 2018 um 3:21 pm #2785022

lydiaP

Hallo Cristina,

vielen Dank für Ihre erneute Hilfe. Die letzten beiden Tipps zur Optimierung von WPML habe ich gerade angewandt. Vielen Dank dafür.

Ihre Inputs zu den Backend-Einstellungen für WP Rocket Cache habe ich den Entwickler gebeten, nochmal anzuschauen. Vielen Dank auch dafür.

Ihre Tipps zu den Pagespeed Messwerkzeugen sind auch sehr nützlich, diese werden wir bei einer nächsten Runde Performance Optimierung sicher gut gebrauchen können. Für dieses Mal schliessen wir die Arbeiten demnächst ab und schauen, wie der Kunde mit den momentanen Ladezeiten beim Publizieren von Beiträgen klarkommt.

Damit könnte auch dieser Support-Thread geschlossen werden.

Vielen Dank nochmals für Ihre Hilfe und alles Gute.

Beste Grüße,
Lydia

Oktober 3, 2018 um 3:22 pm #2785023

lydiaP

My issue is resolved now. Thank you!