Leistungsoptimierung (Webserver)

1. Allgemein

HTTP ermöglicht es, Ressourcen als zwischenspeicherbar zu deklarieren. Sie gelten für eine statisch zugewiesene Lebensdauer, die als Time-to-Live (TTL) bezeichnet wird, als frisch. Jeder Cache in der Anfrage/Antwort-Kette zwischen Client und Server wird ein zwischengespeichertes Objekt bereitstellen, ohne den
Ursprungsserver zu kontaktieren. Die Update-Strategie des HTTP-Caching-Modells ist rein explorationsbasiert,also ein ablaufbasierendes Modell: Sobald eine TTL ausgeliefert wurde, kann die betreffende Ressource nicht invalidiert werden, bevor die TTL abgelaufen
(expired) ist.[13] Je näher ein Web-Cache anm Netzwerk-Edge-Knoten ist, desto mehr verringert sich die Netzwerklatenz.

In mobilen Netzwerken ist die Auswirkung der HTTP-Anfragenlatenz noch gravierender. Zusätzliche Latenz wird durch die mobile Netzwerkinfrastruktur verursacht.  Mit den älteren Mobilfunkstandards 2G und 3G sind Latenzen zwischen 100 ms (HSPA) und 750 ms (GPRS) üblich.

Anmerkung:  2G/3G wird von den Mobilfunkbetreibern in Österreich noch immer als Backup verwendet !

2. Caching-Strategien 

Mehrere Faktoren veranlassen dem z.B. Administrator, einen Cache zum System hinzuzufügen. Häufig beginnt dies mit einer Beobachtung der Latenz oder Effizienz ( dies kann z.B. mittels eines Network Analyzer erfolgen) einer Abhängigkeit bei einer bestimmten Anforderungsrate. Dies kann beispielsweise der Fall sein, wenn festgestellt wird , dass eine Abhängigkeit möglicherweise gedrosselt wird oder auf andere Weise nicht in der Lage ist, mit der erwarteten Last Schritt zu halten.

2.1. Arten von Caches

Einige der schwierigsten Details zur Cache-Implementierung sind die Auswahl der richtigen Cache-Größe, Ablaufrichtlinie und Bereinigungsrichtlinie. Die Bereinigungsrichtlinie bestimmt, wie lange ein Element im Cache aufbewahrt werden soll. Die gängigste Richtlinie verwendet einen absoluten zeitbasierten Ablauf (d. h. sie ordnet jedem Objekt beim Laden eine TTL (Time to Live) zu). Die TTL wird basierend auf den Clientanforderungen ausgewählt, z. B. wie tolerant der Client gegenüber veralteten Daten ist und wie statisch die Daten sind, da sich langsam ändernde Daten aggressiver zwischengespeichert werden können. Die ideale Cachegröße basiert auf einem Modell des erwarteten Anforderungsvolumens und der Verteilung der zwischengespeicherten Objekte auf diese Anforderungen. Daraus schätzen wir eine Cachegröße, die bei diesen Verkehrsmustern eine hohe Cachetrefferquote gewährleistet. Die Bereinigungsrichtlinie steuert, wie Elemente aus dem Cache entfernt werden, wenn die Kapazität erreicht ist. Die am häufigsten angewendete Bereinigungsrichtlinie ist LRU (Least Recently Used).

Dabei werden verschiedene Arten von Caches unterschieden. Das hängt von Ihrer Position im Netzwerk ab:

Client-Cache. Ein Cache kann direkt in die Anwendung als Teil des Browsers, der mobilen App oder einer HTTP-Bibliothek eingebettet sein. Client-Caches haben die geringste Latenz, werden jedoch nicht zwischen Clients geteilt  und sind eher begrenzt in der Größe.
Forward-Proxy-Cache. Forward-Proxy-Caches werden in Netzwerken als gemeinsame Web-Caches für alle Clients in diesem Netzwerk platziert. Da sie sehr nahe an der Anwendung sind, erreichen sie eine erhebliche Verringerung der Netzwerklatenz. Forward-Proxy-Caches können entweder als explizite Proxies konfiguriert werden, indem den Clients Konfigurationsinformationen über Protokolle wie PAC und WPAD bereitgestellt werden oder indem ausgehende, unverschlüsselte TCP-Verbindungen transparent abgefangen werden.

Web-Proxy-Cache. Internetdienstanbieter (Internet Service Providers, ISPs) setzen Web-Proxy-Caches in ihren Netzwerken ein. Neben der Beschleunigung des HTTP-Verkehrs für Endbenutzer reduziert dies auch die Transitgebühren an Internet-Austauschpunkten. Wie Client- und Forward-Proxy-Caches basieren
Web-Proxy-Caches rein auf Expirationen.

Content-Delivery-Network (CDN)-Cache. CDNs bieten ein verteiltes Netzwerk von Web-Caches, das vom Backend gesteuert werden kann. CDN-Caches  sind darauf ausgelegt, skalierbar und multi-tenant zu sein und können massive Mengen an zwischengespeicherten Daten speichern. Wie Reverse-Proxy-
Caches und Server-Caches basieren CDN-Caches in der Regel auf Ungültigkeitsdaten.

3. Komprimierung von Ressourcen und Minimierung von HTTP-Anfragen

Die Minimierung von HTTP-Anfragen ist entscheidend für die Verbesserung der Leistung und die Verkürzung der Seitenladezeiten. Jeder HTTP-Request verursacht zusätzlichen Aufwand und erhöht die Loadtime einer Webseite. Nachstehend einige Möglichkeiten mit welchem HTTP-Requests reduziert werden können:

Eine gute Strategie ist, Dateien zusammen zu fassen. Im Klartext heißt dies mehrere z.B. CSS-Dateien zu einer Datei kombinieren. Der Vorteil besteht darin, dass die Anzahl der Anfragen, die zum Abrufen von Ressourcen erforderlich sind reduziert wird. dies gelingt. falls z.B. CSS-Sprites verwendet werden um , um mehrere Bilder zu einem einzigen Bild zu kreiren um so die Anfragen zu reduzieren.

Auch das reduzieren von  Characters in den Dateien bringt  Erfolge, d.h. z.B. CSS-, JavaScript- und HTML-Dateien, um unnötige Zeichen, Kommentare und Leerzeichen zu evermindern, da kleinere Dateien werden schneller geladen werden. Dabei helfen Tools wie,  CSS-Optimizer, ist ein recht typisches Online-Werkzeug zur Komprimierung. Es gibt aber viele Andere Tools die den Code automatisch minimieren.

Content Delivery Network (CDN), dienen dazu, um statische Assets wie Bilder, Skripts und Stylesheets global auf mehrere Server zu verteilen. Dies reduziert die Distanz zwischen User und Server und verbessert die Ladezeiten. Ein wichtiger Aspekt betrifft natürlich das Browser-Caching für statische Ressourcen. Sobald eine Ressource heruntergeladen wurde, wird sie lokal auf dem Gerät des Benutzers zwischengespeichert, wodurch die Notwendigkeit nachfolgender Requests reduziert wird. Des Weiteren, falls noch im Einsatz, ist es unerläßlich den Server auf HTTP/2 zu migriere. Daturch können mehrere Dateien parallel über einen einzigen Kanal angefordert werden können, und so mehrerer eAnforderungen reduziert. Auch Lazy Loading für Bilder und Videos sollte implementiert werden. Zunächst nur den Kontent laden, der für den Benutzer sichtbar ist, das Laden anderer Ressourcen erfolgt erst, wenn diese angezeigt werden sollen..

Wichtig ist auch die Verwendung von responsive Images, somit stellt man mehrere Größen für unterschiedliche Bildschirmauflösungen und Geräte bereit. Dadurch wird sichergestellt, dass die User nur die entsprechende Bildgröße herunterladen. Auch die Verwendung von Skripten und Widgets von Drittanbietern(Third-Party-Products), die zusätzliche HTTP-Anforderungen erfordern ist zu überdenken.  Nur das verwenden, was für die Funktionalität  der Web.Page unbedingt erforderlich ist.

Die Optimierung der Schriftarteni, Scriftgröße sind auch ein Mosaikstein,um  Requests hinsichtlich der Fonts zu reduzieren, außerdem sollten nr websichere Schriftarten verwendet werden. 

Vermeiden Sie Weiterleitungen: Auch unnötige Redirects sollten vermieden werden, denn jede Weiterleitung generiert einen zusätzlichen  HTTP-Request. Auch die Priorisierung wichtiger Ressourcen sollten  im oberen Seitenbereich (CSS, JavaScript) definiert werden bzw. diese  inline oder asynchron bereitstellen, damit eine  schnelle anfängliche Seitendarstellung zu ermöglichen. Auch die Verwendung von  GZIP für die Komprimierung auf dem Server, um textbasierte Ressourcen zu verkleinern, bevor sie an den Web-Browser gesandt werden, reduziert die Dateigröße bzw. beschleunigt Downloads und ist eine weitere Strategie um die Anzahl der HTTP-Anfragen derr Website erheblich zu reduzierenm was zu einer besseren Usability führt.

4. Optimierung von Ladezeiten und Responsiveness

xxx