Habe festgestellt, dass die einträchtig nebenherlaufende Statistik-Funktion – welche zwar recht schick programmiert ist und mindestens die 3. Normalform aufweist – mittlerweile 5 Millionen Datensätze vorweist. Und in letzter Zeit stellte ich ein paar Lags bei Seitenaufrufen fest. Also habe ich die Statistik jetzt mal aus den Skripten rausgenommen – zumal ja sowieso Google Analytics akribisch alles schön trackt und mir in diversen Charts übersichtlich anzeigt.

Außerdem mal noch – anhand meiner SQL-Log-Funktion – ein paar Indizes für verschiedene Tabellen gesetzt. Es gab hier noch ein paar Abfragen, welche unschöne Wartzeiten verursachten – alles im <1 sec-Bereich – aber die User-Experience ist nun deutlich gestiegen.

Die Entwicklung der beta7 stockt nämlich zur Zeit etwas und so wurde die beta6 noch ein wenig gepimpt für die Wartezeit. Die ganzen schönen Ideen werden zwar festgehalten, aber momentan fehlt es einfach an Zeit für die Weiterentwicklung und Umsetzung. An Lust jedenfalls nicht.

Heute wird mein Dachfenster ausgetauscht – da hab ich etwas Zeit, hier gepflegt an der beta7 (Codename) zu basteln und neue Fortschritte zu präsentieren.

Ich feile gerade am letzten Schliff der Frontend-Performance-Optimierung. Das Backend, wie z.B. die Datenbank-Struktur- und -Queries, ist in der beta6 bereits ganz gut optimiert gewesen. Hier wird die Struktur auf jeden Fall weitgehend übernommen werden.

Einerseits wird es ein Caching von Inhaltsseiten geben, damit diese bei jedem Aufruf nicht neu erzeugt werden müssen. Diese Cache-Dateien haben dann eine Gültigkeit von z.B. 2 Stunden – wobei die Startseite sicher eine geringere Lebensdauer haben muss. Außerdem wird dieses Caching auch erstmal nur für nicht-eingeloggte Benutzer stattfinden. Also zum Beispiel solche die per Google oder einen Link durchschauen wollen und sich nicht registrieren möchten. Der Unterschied ist aber schon enorm: Um den Faktor 10 werden die Seiten schneller ausgeliefert. Statt beispielsweise 0,4 Sekunden stehen dann 0,04 Sekunden auf der Uhr. Mag zwar marginal sein, aber in der User-Experience macht sich das deutlich bemerkbar, wenn nach dem Klick sofort die neue Seite erscheint. Für eingeloggte User wird dann sicher ein Teil-Caching implementiert werden, um wirklich statische Inhalte schneller ausliefern zu können und die Datenbank und den Server zu entlasten. Aber dazu später :-)

Zum zweiten habe ich eine optionale ZLIB-Komprimierung eingebaut, welche die zum Browser übertragenen Daten um etwa 75% verkleinert. Gerade bei HTML-Code ist eine hohe Redundanz und damit Komprimierungspotential vorhanden. Der Client entpackt diese Dateien dann wieder – hierbei ist jeder normale Browser dazu in der Lage. Falls nicht, schickt das Skript die Daten einfach unkomprimiert – hier ist im Code eine Prüfung eingebaut, damit der Benutzer keinen Zeichensalat sieht. Ob die gesparte Übertragungszeit nicht eventuell durch die Zeit zum Dekomprimieren nulliert wird, muss ich aber noch in Feldversuchen eruieren – hieran ist natürlich auch die Clientgeschwindigkeit maßgeblich beteiligt. Der Server sollte damit kein Problem haben – zumal die komprimierten Daten ebenso gecached werden.

Auf jeden Fall eine spannende Sache, und bei entsprechenden Besucherzahlen unabdinglich.

Endlich mal angefasst aufgrund des hohen Nervfaktors: Längere Blogeinträge und solche mit vielen Kommentaren wurde immer nur etwas schleppend geladen. Ich habe nun mal die Datenbank-Abfrage etwas "optimiert" und jetzt läufts wieder gewohnt flott. Das lag mir auf jeden Fall noch vor dem voraussichtlichen Launch der beta7 in diesem Sommer auf dem Herzen.