Wer in den letzten Wochen auf meinem Blog unterwegs war hat es eventuell gemerkt: Irgendwie war das Ganze etwas zäh. Jeder Aufruf dauerte mindestens 5 Sekunden – nur warum?
Also gehen wir die große Frage an: Was ist der Auslöser. Frage einfach, Antwort kompliziert. Erster Anlaufpunkt: das Netz. Um zu prüfen, dass das Problem wirklich am Server und nicht am Netzwerk liegt wird die Seite lokal aufgerufen:
time wget -O - https://adlerweb.info/ > /dev/null
[…]
real 0m5.488s
[…]
Danke, keine weiteren Fragen, am Netz liegt es nicht. Wenn wir aber schon mal da sind rufen wir auch einen statischen Inhalt auf – nehmen wir z.B. einfach mal ein Bild:
time wget -O - https://adlerweb.info/blog/wp-content/uploads/2014/05/header-2014.png > /dev/null
[…]
real 0m0.017s
[…]
Aha – der statische Aufruf funktioniert zügig, damit wäre ein Fehler des Webservers selbst eher unwahrscheinlich. Der PHP-Interpreter oder die Anwendung scheint also Auslöser zu sein. Testen wir mal eine „rohe“ PHP-Datei. Reines echo.
time wget -O - https://adlerweb.info/test.php > /dev/null
[…]
real 0m0.007s
[…]
Somit wäre auch der PHP-Interpreter raus – es kann also eigentlich nur noch WordPress sein, oder? Nunja, ein reines WordPress auf selbem Server ist da anderer Meinung:
time wget -O - https://adlerweb.info/wptest/ > /dev/null
[…]
real 0m0.895s
[…]
Deutlich langsamer als der Testcode, aber es sind ja auch ein paar Zeilen mehr – eine Sekunde ist aber imo noch erträglich. Also muss irgendwas in der Seite den Fehler verursachen – Plugins, Themes, Anpassungen. Viele Kandidaten.
Erster Versacht: Meine Solarstatistiken. Diese müssen sich erst durch meinen heimischen Anschluss quetschen und der ist nicht gerade der schnellste. Statistik aus, aber trotzden: 4.925s. Kein Wunder: Es sind ja nur wenige Zeichen Text und spätestens beim zweiten Aufruf wären sie im Cache des Servers. Also weiter geht die Deaktivierungsorgie, aber mit Nachbrenner.
Um herauszufinden ob ein Plugin oder sonstiger Code das Problem verursacht wandern alle Plugins temporär aus dem WordPress-Ordner in ein temporäres Verzeichnis. Bingo: Ohne Plugins lädt die Seite in gerade mal 0.265s – suchen wir den Schuldigen. Plugin für Plugin wird dieser eingerichtet, dabei stechen einige hervor:
– apc: +1,2 Sekunden
– wp-slimstat +0,3 Sekunden
APC war früher als Cache im Einsatz, heute ist das Plugin im Backend deaktiviert, aber durch einen damals nötigen Symlink werden offenbar trotzdem Teile des Plugins geladen. Die Ladezeit steigt dabei offenbar mit der Codegröße – wenn mehr andere Plugins geladen sind erhöht sich die Ladezeit mit APC prozentual. Wie schon gesagt: Historie – kurze Sache: Weg damit.
WP-Slimstat ist ebenfalls etwas auffällig, wenngleich weit entfernt von der Bremswirkung des vorherigen Kandidaten. Slimstat sah mir nach einer guten Idee aus – der Webserver anonymisiert bereits die IPs, entsprechend kann ich hiermit lokale & anonyme Statistiken generieren. Den Performance-Impact hatte ich mir allerdings nicht ganz so groß vorgestellt, als Alternative hat sich jetzt WordPress Statistics von Mostafa Soufi eingefunden – mit diesem Plugin kann ich keien messbare Verschlechterung feststellen.
Ergebnis des Frühjahrsputzes (a2b, 100 Requests, 10 Parallel):
Vorher: Ohne APC: Andere Stats 100 Requests 100 Requests 100 Requests 146.809 seconds 24.047 seconds 14.385 seconds 6282600 bytes 6282600 bytes 6240100 bytes 42.08 Kbytes/sec 256.91 Kbytes/sec 426.60 Kbytes/sec =================== ================== ================== 1468.093 ms/Request 240.471 ms/Request 143.846 ms/Request 0.68 Requests/sec 4.16 Requests/sec 6.95 Requests/sec
Durch löschen des alten Plugins konnte die Ladezeit um 83% gesenkt werden – mit neuem Statistikplugin waren sogar weitere 7% Reduktion möglich. Ein zehntel der Ladezeit – nicht schlecht für eine eigentlich so kleine Ursache…
Wir lernen: Man sollte öfter mal aufräumen, nicht mehr verwendete Plugins auch aus dem Dateisystem entfernen und Plugins vor der Nutzung vergleichen…