Schon seit längerem war deutlich zu spüren, das dieser Blog nicht mehr der Schnellste ist. Tipps und Tricks gibt es eine Menge, was man tun kann, geholfen haben in diesem Fall zwei Maßnahmen.

Zugegeben, auf Performance war’s hier nie optimiert. Zweifelsohne kann man einiges mit z.B.

• Dedicated Server
• QuickCache, Proxy usw.

anstellen. Ein Klassiker möglicher Flaschenhälse ist das PHP Memory Limit, dies war bereits in der Vergangenheit einer der Gründe, warum ein Providerwechsel nötig wurde. Aktuell belegt diese Installation aber gerade mal 59.84 MB von max. 256 MB. Da kann man nicht meckern.

Schon längere Zeit hatte ich im Hinterkopf weniger Werbung und folglich damit weniger externe Inhalte (Die erstmal geladen werden müssen!) im Blog zu schalten, zumal da ohnehin so gut wie nichts mehr bei rum kommt. Vor längerer Zeit verschwand deswegen bereits das Skyscraper-Banner in der Sidebar.

So blieb nur noch das Banner zwischen Titelzeile und Beitragsinhalt, dies war aber nur sichtbar wenn

• ein Beitrag aufgerufen wurde oder
• kein AdBlocker eingesetzt wird.

Ersteres dürfte sich somit nicht auf die Startseite auswirken und letzteres gehört sich (imho) heute nicht mehr. So oder so und weil’s eben schon länger angedacht war, wurde das Plugin “Ad Injection”, was für das Banner in den Beiträgen verantwortlich war, deaktiviert.

Das brachte (gefühlsmässig) schon mal was, wenn man einen Beitrag öffnet. Was aber mit der Startseite machen?! Eine schnelle Recherche führte zu

6 Tipps: So wirst du dein langsames WordPress Admin Dashboard los

und in Folge zu

Datenbank optimieren mit phpMyAdmin

Also kurzerhand im Backend des Providers angemeldet, phpMyAdmin angeworfen und mal schnell die Datenbank optimiert und siehe da, es rennt.

Laut Pagespeed.de sank die Ladezeit von über 10 Sekunden auf 1,4 Sekunden. Damit kann man leben.

Update 17.05.2015 – 1

Ganz rund ist’s noch nicht. Zeitweise kommt es zu MySQL-Verbindungsabbrüchen, weswegen ich den Support kontaktiert habe. Parallel dazu habe ich den Eindruck, das es von der Tageszeit abhängt, wie gut der Blog erreichbar ist. Das mag aber daran liegen, das beim aktuell verwendeten Tarif bis zu 50 Kunden auf einem Server liegen.

Update 17.05.2015 – 2

Vom Support kam folgende Meldung zurück:

Folgende Anfragen finden sich gehäuft im Slowquerieslog:

SELECT COUNT(*) FROM (SELECT 1 FROM DBPRÄFIX_cpd_counter GROUP BY date, ip) t;

Vermutlich blockieren diese Anfragen die Verbindung zur Datenbank.

Diese Abfragen gehören zum Plugin Count per Day, sucht man danach findet man z.B. folgende Treffer:

WordPress – Support – Count per Day
[resolved] WP Count Per Day make my db larger

Daraufhin habe ich mal zwei Massnahmen in den Einstellungen des Plugins ergriffen:

WordPress - Einstellungen - Count per Day - Registerkarte "Werkzeuge" - Abschnitt "Alte Daten zusammenfassen"

Auf die Schaltfläche “Alte Daten zusammenfassen”.

Damit wird schon mal “etwas” aufgeräumt. Die zweite Massnahme ist:

WordPress - Einstellungen - Count per Day - Registerkarte "Einstellungen"

Den Haken entfernen bei “Browser und Herkunft speichern und anzeigen.” und auf die Schaltfläche “Einstellungen aktualisieren” klicken.

Zur Sicherheit dann nochmal eine Optimierung des Datenbank via PhpMyAdmin, dabei konnte man schon gut geobachten, wie klein die Tabelle “DBPRÄFIX_cpd_counter” wurde (von ursprünglich über 300 MiB auf gute 100 MiB).

Mal sehen, ob’s was bringt.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.