Need for Speed

Schon seit Anbeginn von www.beatsblog.ch stellen wir eine signifikante Verlangsamung fest, sobald ein einzelner Beitrag aufgerufen wird. Dies habe ich vor über einem Monat auch dem Manitu-Support gemeldet. Seither gab es ein paar Mails, vorwärts und zurück, doch das Problem ist immer noch da und keiner weiss so genau, wie weiter. Hier ein Beispiel:

www.beatsblog.ch (hosted by manitu) https://www.beatsblog.ch/1230-zum-zweiten-Mal.html -> Seitenaufbau 4.19 sec. davon 3.77 Wait ?

www.blog.dokumenzi.ch (hosted by hosttech) https://www.blog.dokumenzi.ch/1230-zum-zweiten-Mal.html -> Seitenaufbau 0,52 sec. davon 0.18 Wait ?

Heute nun habe ich mir Zeit genommen um auf dem Manitu-Webspace eine Subdomaine einzurichten. Darauf installierte ich eine aktuelle Styx Dev 3.0 alpha4 Version. Danach exportierte ich aus der DB von www.beatsblog.ch die entries-Tabelle und importierte diese in den leeren Blog. Das heisst, keine Plugins, keine Bilder, kein spezielles Template, keine Kategorien, keine Tags, kein irgendwas...

Das Resultat:

www.styx.beatsblog.ch (hosted by manitu) https://styx.beatsblog.ch/1230-zum-zweiten-Mal.html -> Seitenaufbau 0,43 sec. davon 0.1 Wait ??

Grummel... Es sieht also verdammt so aus, als ob ich selbst die Verzögerung irgendwo eingebaut habe. ?

Alle weiteren Schritte im Erweiterten Beitrag

20.03.2020, 23:00 Uhr

Habe alle Bilder (/uploads) von www.beatsblog.ch nach styx.beatsblog.ch kopiert.

Folgende DB-Tabellen habe ich aus www.beatsblog.ch exportiert. Per Editor ersetzte ich wo nötig die www-Adresse oder den Benutzernamen. Danach importierte ich die Daten in die entsprechenden Tabellen von styx.beatsblog.ch

• styx_entryproperties
• styx_images
• styx_mediaproperties
• styx_permalinks
• styx_references

zusammen mit den styx_entries und styx_comments Tabellen wurden bisher also 7 Tabelleninhalte übernommen. Ein paar Checks zeigten, dass -zumindest auf den ersten Blick- alles soweit noch stimmt und schnell funktioniert.

Zudem habe ich die Konfiguration des nl2br-Plugins auf "Kommentare" reduziert. Somit passt auch die Textdarstellung wieder.

Aktuelle Messungen:

• Indexseite - styx.beatsblog.ch = 2,7MB, 44 Requests, 545ms, davon 217ms Wait
• Einzelbeitrag  - styx.beatsblog.ch/2630-relax-and-enjoy-life.html = 1,7MB, 26 Requests, 489ms, davon 137ms Wait

Dann habe ich zusätzlich zu styx.beatsblog.ch noch die Subdomaine www.styx.beatsblog.ch eröffnet. Die Geschwindigkeit bei beiden Adressen (mit oder ohne www) ist ziemlich identisch.

Und ich konnte es nicht lassen: Ich kopierte das PURE-BEAT-Theme und aktivierte es. Phu, bin ich froh, dass nicht mein Template die grosse Wartezeit verursacht. Nun liegen die Messungen bei:

• Indexseite - styx.beatsblog.ch = 2,8MB, 50 Requests, 665ms, davon 170ms Wait
• Einzelbeitrag  - styx.beatsblog.ch/2630-relax-and-enjoy-life.html = 1,8MB, 31 Requests, 420ms, davon 45ms Wait

Was mir bei den pingdom.com- und auch GTmetrix.com-Speedtests auffällt. Es wird immer angezeigt, dass gzip-Kompression verwendet werden soll. In der S9Y-Konfiguration ist dies aktiviert (habe nochmals nachgesehen). Bist Du sicher, dass dies auch funktioniert?

21.03.2020 11:30 Uhr

Ich habe mir überlegt, wie ich weiter vorgehen soll. Zur Auswahl stand: Ich importiere alle DB-Tabellen, die es meiner Ansicht nach noch braucht und beginne erst danach alle Plugins zu installieren oder eben umgekehrt. Zuerst die Plugins und dann die noch fehlenden Daten. Die Entscheidung fiel auf: DB-Daten zuerst.

• styx_categories
• styx_categorytemplates
• styx_entrycat

Hmm... ? Irgendwie hapert die Selektion der Kategorien noch. Vermutlich muss ich Template- und Browsercache mal leeren. Hat leider nichts gebracht. Unter /Inhalt/Kategorien sowie in der Seitenleiste wird die richtige Anzahl an Beiträgen angezeigt. Ein Klick auf einen Kategorien-Link führ aber keine Selektion durch. ? Es könnte noch damit zusammenhängen, dass ich im Original-Blog das Plugin für "Erweiterte Kategorie-Eigenschaften" im Einsatz habe.

Nun installierte und konfigurierte ich diese Ereignis-Plugins:

• categorytemplates
• ckeditor
• lightbox

Das Selektionsproblem bei den Kategorien hat sich dadurch nicht gelöst. Egal. Hier eine Zwischenmessung bezüglich Geschwindigkeit:

• Indexseite - styx.beatsblog.ch = 2,9MB, 59 Requests, 917ms, davon 262ms Wait
• Einzelbeitrag  - styx.beatsblog.ch/2630-relax-and-enjoy-life.html = 1,9MB, 39 Requests, 688ms, davon 142ms Wait
• -> es wurde schon etwas langsamer, doch immer noch im grünen Bereich.

Import von DB-Tabelle styx_entrytags und Installation/Konfiguration des freetag-Plugins. Funktioniert! Insgesamt habe ich nun 11 DB-Tabellen importiert (es fehlen eigentlich nur noch die 2 für Statische Seiten). Es sind im Moment 6 (von 7) Seitenleisten-Plugins und 12 (von 21) Ereignis-Plugins installiert. Noch sieht alles gut und schnell aus. ?

Seitenleiste:

• links: Kommentare hinzugefügt
• rechts: History-Plugin hinzugefügt
• rechts: Syyndication-Plugin angepasst
• rechts: imagesidebar-Plugin hinzugefügt
• rechts: HTML-nugget (für Styx) hinzugefügt
• archives-Plugin versteckt
• superuser- und powered-Plugin gelöscht

Soweit sind jetzt alle Seitenleisten-Plugins installiert (8 Stk.). Später werde ich das category-Plugin nich löschen und das freetag-Plugin verstecken. Dann ist die Situation identisch wie hier und auf www.beatsblog.ch.

Hier eine Zwischenmessung bezüglich Geschwindigkeit:

• Indexseite - styx.beatsblog.ch = 3,0MB, 62 Requests, 1'140ms, davon 446ms Wait
• Einzelbeitrag  - styx.beatsblog.ch/2630-relax-and-enjoy-life.html = 2,0MB, 43 Requests, 771ms, davon 308ms Wait
• -> mit den zunehmenden Request und der stets grösseren Seitengrösse, verlangsamt sich alles. Dennoch: Ein Einzelbeitrag wir immer noch schneller angezeigt, als eine Indexseite. So sollte es auch sein.

FULL-STOP! Plötzlich habe ich eine zündende Idee! ? -> das Plugin für die Nächste oder Vorherige Seite (entrypaging) ist das einzige Plugin, welches nur auf Single-Entry-Seiten aktiv ist. Also mal testweise auf www.beatsblog.ch ausschalten... HEUREKA! ✔ Das ist der Übeltäter! Somit kann ich die Aktionen hier mit gutem Gewissen abbrechen.