Leistungsoptimierung

Mit der Optimierung der Leistungen der Powersoftwareprodukte beschäftigen wir ja uns permanent.
Und Optimierungen kommen und gehen.
Sie kommen dann wenn sie notwendig und machbar sind, sie gehen dann, wenn es bessere Methoden gibt oder andere Methoden erforderlich werden.

Wir haben nun mal die HTML5 Zeiten und wir haben auch wunderbare Browser die richtig etwas leisten können und wir haben auch die Situation, das der mobile Zugriff bereits Standard und nicht die Ausnahme ist.

Das Ziel ist unverändert die Inhalte mit maximaler Geschwindigkeit zu generieren , mit den Pagespeedmethoden und  HTML5 heißt es, diese Dinge programmtechnisch zu unterstützen.
Mit der Unterstützung von Pagespeedmethoden sind wir ja so gut wie durch, neu ist die Ergänzung über die HTML5 Unterstützung.

Hier haben wir uns auf die Dinge konzentriert die am meisten belasten, das sind Images.

Jedes Image ein Request, überträgt man diese per Base64 fällt der Request weg, aber das Transfervolumen steigert sich.

Aktuell verringern wir schon mal den Aufwand der Base64 Generierung.
Während wir vorher diese generierten Images als File gecacht haben, liegen sie nun in einer eigenen Sqlite DB.

Das hat den Vorteil, das je nach Webgestaltung und Inhalt viele tausend Files weg fallen - Sqlite hat nur ein einziges File.
Und - der Zugriff darauf über SQL ist tatsächlich schneller als der direkte Filezugriff.

Aber - wir gehen noch weiter.

Wir bieten die Möglichkeit diese Images über Ajax zu laden, das entlastet das Volumen des HTML Codes und wegen der parallelen Übertragungsmöglichkeit geht das sogar schneller.

Und wir gehen noch weiter !

Wir prüfen mit dem Ajaxscipt ob das Image vielleicht schon im local Storage des Besuchers abgelegt ist, wenn ja, wird es von dort aus auf den Schirm gebeamt, wenn nein, wird es aus der DB geholt, dargestellt und in den local Storage des Besuchers abgelegt.

Diese Methode aber reduziert das Transfervolumen drastisch - der Gewinn ist deutlich höher als der Verlust.

Und rechnen wir das mal alles zusammen mal Anzahl der aktiven Besucher ergeben sich enorme Entlastungen des Servers selbst und das bedeutet - alles wird schneller und man kann mehr Besucher gleichzeitig bedienen.

Da der local Storage des Besuchers solange erhalten bleibt bis er gelöscht wird, hält der Effekt auch entsprechend lange an, im Zweifelsfall werden diese Images nie wieder transferiert.

Was man mit der Methode auch erreicht ist die Reduzierung der Zeit für das First Byte, ohne dem ein Browser überhaupt nicht anfängt aktiv zu werden.

Dieses Beispiel dient dazu mal aufzuzeigen, das Optimierungen nicht nur in Richtung dem eigentlichen Programm und seine Generierungszeit gehen muss, es kommt darauf an auch die Zeitstrecke auch nach dem Abfeuern des Inhaltes zu beschleunigen.
Und gerade da lässt sich an Speed für den Besucher richtig etwas heraus holen, weitaus mehr als bei der Generierungszeit gespart werden kann.
Solche Maßnahmen aber können, geschickt ausgeführt, den Server und die Anwendung ebenfalls in der Summe enorm entlasten.

Pagespeedkenntnisse sind nützlich um die Zusammenhänge zu erkennen, aber man hat daraus auch gelernt, das es Webs mit Pagespeed 100/100 gibt, die dennoch langsam sind und zwar so langsam, das sie ungenießbar sind.

Schaut man sich diverse andere Produkte an erkennt man, das extrem RAM verschleudert wird.
Der RAM Bedarf einer Anwendung ist eine direkte Aussage über den Speed.

Wer selbst mal außerhalb von Webs programmiert hat, weiß das ein Assemblerprogramm allen anderen mit gleicher Aufgabe aber in einer Hochsprache definiert davon läuft und das liegt auch an den RAM Bedarf.

Auch bei einem Webserver ist der RAM begrenzt. Und hier muss man jedes Byte mit der Anzahl der durchschnittlich gleichzeitig aktiven Besucher multiplizieren.

Hat man also 100 Besucher und verschleudert 10KB unnütz, wird der Server mit 100x 10KB = 1 MB belastet.

Diese einfache Rechnung zeigt deutlich auf die Schwachstellen von Programmierungen.

PHP Klassen einzusetzen ist sinnvoll, diese aber für jeden Kleinkram auszuweiten und einzusetzen ist für die Performance tödlich und man verliert letzten Endes auch den Vorteil der einfacheren Wartung.

Und - Klassen kosten richtig RAM.

Wer Scripte durchschaut erkennt auch eine Vielzahl von einfachen Mängeln wie z.B. Variable die nach der Nutzung nicht entfernt werden und somit RAM kosten, die in ihrer Summe belasten.

So verbleibt zu häufig der letzte Wert einer foreach Schleife im Speicher und das ausgerechnet da wo jeder einzelne Wert richtig heftig Bytes kostet.

Das Problem bei vielen Webprogrammierern ist, das sie nicht die Reichweite einer noch so winzigen Optimierung erkennen.
Die sehen ein paar KB RAM , die sehen kleinste Zeiteinheiten und sehen nicht die Summierung dieser Kleinigkeiten wegen der Anzahl der Nutzer und sie sehen nicht die  reale Geschwindigkeit die beim Nutzer ankommt.
Und sie erkennen auch nicht, das man, wenn die reale Zeit in einem gewissen Fenster liegt das psychologisch definiert wird, man durch die Einsparungen auch noch weitere Inhalte abliefern kann, die vorher das Zeitfenster gesprengt haben.

Das reale Zeitfenster liegt optimal bei 1 Sekunde oder kleiner und damit ist die fertig gerenderte Seite gemeint. Das Zeitfenster und die Zufriedenheit der Nutzer wird langsam kleiner und sackt bei 2 Sekunden steil nach unten.

Was man berücksichtigen muss - mobile Einheiten sind technisch bedingt bis zu 10 x langsamer.
Da geht es nicht nur um eine optimale Darstellung (Thema responsive Webdesign) sondern ganz klar geht es darum den Besucher bei der Stange zu halten.

Mobile Nutzer wissen natürlich das dieser Zugriff  langsamer ist, die psychologische Grenze ist damit aber nicht aufgehoben sondern bestenfalls gedehnt.
Diese Nutzergruppe wird sich die Webseiten als Favoriten eintragen, die schneller sind als andere.
Die oben beschriebene Technik des local Storage oder wie von uns auch genutzt der Application Cache erzeugt wahre Wunderdinge - wenn ein System es unterstützt.

Universalsysteme

Das sind solche die über zahlreiche Module erweitert werden können.
Die haben alle einen Overhead damit solche Module überhaupt arbeiten können und sie wissen nicht welches Module gerade auf einer Seite aktiv ist - das ist ein ganz dickes Performanceproblem, das umso auffälliger wird, je mehr man davon einsetzt.

Solche Systeme fallen in die Rubrik alle Aufgaben befriedigend zu lösen aber keines wirklich sehr gut.

Popularität haben diese  Systeme gerade von kleinen Anwendern gewonnen, die fachlich nicht versiert sind, meist auch kleine Standardwebs mit 10.. 20 Seiten damit erstellen und das aus ihrer Sicht natürlich für eine tolle Lösung halten.
An Performance und ihre Folgen wird nicht gedacht.
Im Zweifel wird dann richtig Geld in leistungsfähigere Server investiert um solche Mängel auszugleichen - doch das funktioniert nur bedingt.

Es gibt nur ganz wenige Systeme die Moduletechnik anbieten um die Leistung der Module im Frontend durch ganz simple Plugins abzurufen, die nur dann Zeit kosten wenn sie auch tatsächlich eingesetzt werden.

Wer wirklich die maximale Performance will und damit die höchste Kundenzufriedenheit, der setzt auf angepasste Systeme, die genau das machen was sie sollen und das mit Höchstleistung.
Die sind unterm Strich billiger als Universalsysteme und wenig anfällig bezüglich Updates oder gar Änderungen.

Man sollte sich auch mal ansehen welche Systeme die ganz dicken Haie im Internet verwenden - da wird man garantiert kein Typo3 oder Cmsmadesimple finden.

Ein Blick in den Source werfen

Wer Source lesen und verstehen kann, der sollte mal einen Blick auf die Datenbankabfragen werfen.
Systeme die z.B. derart aufwendig wie z.B. Cmsmadesimple nur eine Menüstruktur mit zahlreichen Abfragen und zwischendurch jede Menge PHP aufbereiten, die sind für hohe Anforderungen absolut ungeeignet.

Ein System das nicht in der Lage ist die ganze Menüstruktur mit einer einzigen Abfrage in der Datenbank zu holen das taugt nichts.

Tatsächlich gibt es davon eine Menge Systeme die - insbesondere bei starker Verschachtelung - 50 oder auch 300 und mehr Datenbankabfragen benötigen zusätzlich noch zwischendurch die PHP Aufbereitung.

Diese Systeme sind bestenfalls für kleine Websites mit 10..20 Seiten geeignet und das auf hochwertigem Webspace und haben dennoch den Nachteil der künstlichen Beschränkung der maximalen Anzahl von Besuchern die gleichzeitig kommen können.

Wer es extrem liebt, der sollte, wenn er kann, sich sein Zielsystem auf einen lokalen Server packen und den einem Stresstest unterziehen.

Bei den oftmals gehandelten Namen in der CMS - Szene wird er dann sehr schnell sein Wunder erleben, weil der Testserver bereits bei relativ harmlosen Mengen aktiver virtueller Nutzer aussteigen wird.