Die schönste Webseite trifft nur dann auf den Zuspruch der Anwender, wenn sich zur Ausfallsicherheit auch eine hohe Performance gesellt. Um diese zu gewährleisten und zu verbessern muss man sie messen können. DigitalMasters vermittelt das benötigte Fachwissen in einer Serie von Beiträgen:
- Wer braucht Spitzenperformance: die Bedeutung der Benutzererfahrung
- Web Performance Monitoring in der Praxis: Die Erreichbarkeit einer Webseite ermitteln und verbessern
- Bedarfsgerechtes Hosting für erfolgreiche Websites: die Vorteile der Cloud
- DNS-Lookup im Cloud-Zeitalter: Diagnose
Wer braucht Spitzenperformance: die Bedeutung der Benutzererfahrung
Der Wettbewerb in der IT-Branche ist immer für eine Überraschung gut; der eine oder andere Dinosaurier, der sich weigerte, die Zeichen der Zeit zu erkennen, erlebte ganz unerwartet eine harte Landung (neuestes Beispiel: IBM). Die großen Dinosaurier haben es dennoch vergleichsweise leicht. Für den Mittelstand, kleine IT-zentrische Unternehmen (und erst recht für Selbstständige) ist die Kunst, IT-technisch am Ball zu bleiben, überlebenswichtig. Wer zu lange zögert, erleidet oft Schiffsbruch.
Dennoch sind die Wenigsten dazu in der Lage, rechtzeitig auf Korrekturkurs hin zu steuern. Innovationen bringen nämlich eigene Risiken mit sich.
Standen die Risikokapitalinvestoren einst Schlange, um Studienabbrecher mit viel freier Zeit zu hofieren, so hat sich die Lage deutlich normalisiert. Allein mit Begriffen wie „Dot.com“ und „E-Commerce“ kann man schon lange niemanden mehr hinter den Ofen locken. Auch wird kaum jemand einem reinen „Dot.com“-Unternehmen für eine bloße Idee Geld zahlen (massive Benutzerzahlen sind wiederum etwas ganz anderes). Nach der Acquisition eines bereits schlanken Startups werden Kosten gesenkt, der Service verbessert und Kundenbindung gepredigt.
Kostensenkung? Service? Kundenbindung? Wie soll das alles gelingen, wenn der potenzielle Online-Käufer schon nach wenigen Sekunden Warten zur Konkurrenz weitersurft? Das Überleben von Unternehmen steht und fällt mit der sofortigen Auffindbarkeit und Erreichbarkeit ihrer Webshops, Webseiten und dem Reaktionsvermögen ihrer sozialen Identitäten (insbesondere Twitter hat sich als eine Service-Plattform für den Kundendienst bewährt).
Wie in kaum einer anderen Branche zählt bei der Web-Performance einer Website der erste Eindruck. Wenn der Seitenaufbau zu lange dauert, ist der Besucher einer Webseite geneigt, sich das leidige Warten zu ersparen. Hat eine Webseite erstmal den Ruf träge zu sein, so lässt sich das nur schwer revidieren.
Die häufigsten Ursachen für schwache Website-Performance
Zu den häufigsten Ursachen für Performanceprobleme zählen:
- unterdimensionierte Infrastruktur: langsame virtuelle Hosts, marode Webserver, schlecht konfigurierte oder schlicht überlastete Datenbanken;
- überflüssige Redirections;
- unzureichende geografische Nähe zum Endanwender;
- schlecht programmierte Webseiten;
- Server-Ausfälle aufgrund mangelnder oder unzureichender Redundanz;
- unerwartete Belastungsspitzen;
- Störungen, die durch Wartungsarbeiten und Updates verursacht werden,
- Sabotage (darunter die immer umfassenderen DDoS-Attacken für Lösegeld).
Diese und andere Ereignisse hinterlassen beim Webbesucher einen schlechten Eindruck, auch wenn die betreffende Website sonst sowohl inhaltlich als auch technisch brilliant umgesetzt wurde.
Es ist immer einfacher, Webbesucher für eine kontinuierlich gepflegte, durchdachte und interessante Webseite zu begeistern und ihre Loyalität zu gewinnen als Kunden, die man bereits verloren hat, wieder von der eigenen (hoffentlich verbesserten) Servicequalität zu überzeugen. Während man über den Begriff “interessant” durchaus geteilter Meinung sein kann, ist die „Quality of Service“ (QoS) im Falle einer Webseite konkret und exakt messbar.
Die Lösung nennnt sich Web Performance Monitoring. Gemeint sind Methoden zum Messen und Überwachen der Website-Performance, um möglichen Ursachen von Leistungsengpässen frühzeitig auf die Spur zu kommen.
Webserver-Performance messen und auswerten
Um die effektive Performance eines Webservers zuverlässig zu ermitteln nimmt man zuerst die technischen Zusammenhänge unter die Lupe.
Die Kommunikation zwischen dem Client und dem Server verläuft in mehreren Phasen vom DNS-Lookup über die Übertragung der Daten bis hin zum Rendern der Darstellung im Webbrowser. Die kleinsten Verzögerungen summieren sich zu beachtlichen Wartezeiten.
Dienste wie pingdom.com erlauben es Ihnen, die Uptime Ihrer Webseiten zu überwachen und etwaigen Dienstausfällen auf die Spur zu kommen.
Tipp: Unter der Adresse tools.pingdom.com können Sie konkreten Webseiten im Hinblick auf ihre tatsächliche Leistung auf den Zahn fühlen, um die Ursachen von Performanceproblemen zu untersuchen.
Die Anfrage-Rückantwort-Schleife
Die Anfrage-Rückantwort-Schleife läuft beim Aufruf einer Webseite in mehreren Phasen ab:
[1] DNS Lookup (Umsetzung des Domain-Namen in die IP-Nummer)
[2] TCP/IP-Verbindungsaufbau
[3] URL-Anforderung (Request)
[4] ggf. eine Umleitung (Redirection)
[5] Datenfreigabe durch den Server beziehungsweise die Weitergabe der Anfrage an andere Prozesse (üblicherweise Skripte oder Applikationsserver)
[6] Datenübertragung zum Client (hier zahlt sich jede Optimierung der Dateigröße mehrfach aus)
[7] Rendern der Darstellung im Browser (hier spielt die Qualität des HTML- und Skriptencode eine entscheidende Rolle).
Die effektive Performance der Anfrage-Rückantwort-Schleife ergibt sich aus dem Zusammenspiel der folgenden Faktoren:
- Qualität des Website-Materials (Dateigrösse, Qualität des Programmiercode, Redirections, etc.),
- der effektiven Leistungsbereitschaft der Internet-Infrastruktur (Backbone-Anbindung und die Bandbreite des Anwenders),
- Architektur an der Serverseite (Cache-, Daten- und Applikationsserver sowie die Verwendung eines CDNs inklusive).
Der erste Faktor betrifft alle Webpräsenzen und verursacht vergleichsweise moderate Kosten.
Tipp: Eine professionelle Bildbearbeitungssoftware (z.B. Adobe Photoshop) ermöglicht automatisierte Optimierung von Webbildern, welche die Serverbelastung minimiert ohne die Qualität aufs Spiel zu setzen.
In der Regel neigen Webdesigner zu einem gemischten Softwarepool – also mit Produkten und Diensten verschiedener Anbieter. Wer jedoch auch sonst Adobe-Produkte (Illustrator, Photoshop, Premiere Pro, etc.) verwendet, entscheidet sich beim Webdesign meist für Adobe Dreamweaver, um Synergieeffekte zu erzielen und die Lernkurve flach zu halten. Beim Webdesign in der Adobe-Umgebung können Sie dank SmartObjects Dateien in den Originalformaten u.a. von Photoshop und Illustrator verwenden, und Dreamweaver die automatische Konvertierung in websichere Formate überlassen. Beim Laden von PSD-Grafiken in Dreamweaver werden die einzelnen Photoshop-Ebenen als einzelne Bilder für das Web optimiert (JPEG oder PNG) und in sogenannten Schweberahmen positioniert. Der HTML-Code der Seite entsteht automatisch.
Die Verwendung von leistungsfähiger Software zum Erstellen und Optimieren der Inhalte zählt zu den einfachsten Methoden, die Performance einer Webseite zu verbessern. Im Gegensatz dazu ist eine leistungsfähige Anbindung an die Internet-Infrastruktur mit Kosten verbunden. Dieser Performancefaktor besitzt zwar eine hohe Relevanz, ist jedoch nicht ausschlaggebend.
Den Webseitenaufbau optimieren
Latenzempfindliche und bandbreitenkritische Dienste (wie Big-Data-Echtzeiterfassung und Multimedia-Präsentationen) erfordern eine besonders durchdachte Wahl des Standorts.
Online-Besucher, die mal eben nur die Kontaktadresse nachschlagen wollten, sollten nicht mit Bandbreite füllenden Videos gehindert werden. insbesondere die Navigation sollte sich durch eine hohe Usabilitz auszeichnen. Wie oft ein enttäuschter Zuschauer das Warten vorzeitig aufgibt werden die Designer und Programmierer der Website wahrscheinlich nie erfahren. Dabei liessen sich solche Situationen vermeiden. In der Qualität des Datenmaterials liegt ein großer Spielraum für kostengünstige Optimierungen.
Je kürzer die Strecke, die die Bits und Bytes hinter sich bringen müssen, umso niedriger die Komplexität der Aufgabe und – bei gleicher Bandbreite – die Übertragungszeiten. Die Lösung im Cloud-Zeitalter ist genauso simpel wie die Aufgabenstellung, sie nennt sich: Stützpunktserver (Englisch “edge server”). Ihre Aufgabe besteht darin, die Strecken zu verkürzen, die die Daten bis zum Betrachter zurücklegen müssen. Dass sich solche Investitionen natürlich nur bedingt rechnen und selten wenn überhaupt rechtfertigen lassen, ist klar. Für einmalige Ereignisse mit globaler Reichweite wie etwa eine wichtige Konferenz kann man natürlich Rechenleistung zusätzlicher Stützpunktserver von Anbietern wie AWS (oder Akamai) anmieten (Letzteres ist für ein Großteil der Unternehmen unbezahlbar). Die meisten Firmen haben nur eine Hand voll Webseiten und beauftragen damit nur einen einzigen Dienstleister. Wird die Website in den USA gehostet, so erfolgt der Seitenaufbau – sogar bei einer besseren Netzanbindung – für einen Betrachter hier zu Lande nicht schneller, sondern meist sogar langsamer als wenn der betreffende Webserver in Europa stünde. Der Standort des Dienstleisters ist für den Routingaufwand nicht ohne Bedeutung.
Jedes eingebundene Objekt einer Webseite muss zudem vom Client separat angefordert werden. Dies erfolgt nachdem das Hauptdokument – meist die HTML-Seite – übertragen und interpretiert wurde. Laufzeitverzögerungen auf dem Weg vom Server zum Client summieren sich also und werden sich mehrfach fortpflanzen. Erst die Einführung von HTTP/2 erfolgt eine per Protokoll erwirkte asynchrone Datenübertragung.
Die effektive Leistung unterliegt (trotz statischer Kapazitäten) deutlichen Schwankungen in Abhängigkeit von der aktuellen Auslastung der Infrastruktur. Auch hier hat der Betreiber der Seite wenig oder gar keinen Einfluss auf das Tempo, zumindest nicht ohne zusätzliche Investitionen.
Schließlich hängt die erzielte Leistung der Verbindung auch von den verwendeten Protokollen ab. Die neueste Version 2 von HTTP (Hypertext Transport Protocol), HTTP/2 liefert eine deutlich höhere Performance im Vergleich zu seinem Vorgänger, HTTP 1.1, insbesondere im Zusammenhang mit SSL-Verbindungen. Man sollte die Verwendung der deutlich langsameren Vorgängerversion 1.1 vermeiden.
Performance von TCP/IP versus UDP/IP
Messungen der Netzwerkperformance sollten, falls möglich, den Typ des Protokolls berücksichtigen.
Die Steuerung der Kommunikation zwischen dem Client und dem Server in der Transportschicht übernimmt TCP/IP (Transmission Control Protocol auf IP-Basis) oder UDP/IP (User Datagram Protocol auf IP-Basis).
TCP/IP (RFC 793) ermöglicht das Zusammenstellen der Daten beim Empfänger aus Segmenten auch dann, wenn die einzelnen Pakete dort in falscher Reihenfolge oder unvollständig ankommen. Bei TCP/IP wird für jedes Datenpaket eine Empfangsbestätigung erwartet. In der Praxis wird es so gehandhabt, dass der Empfänger alle in einem bestimmten Zeitraum erhaltenen Datensegmente (Empfangsbestätigung, engl. Acknowledge) bestätigt. Sollte diese innerhalb einer vorgegebenen Zeit ausbleiben, wird das jeweilige Paket erneut vom Server verschickt und die Prozedur so lange wiederholt, bis entweder eine Bestätigung ankommt, oder aber die vordefinierte Anzahl wiederholter Versuche vom Server erreicht wurde. Zwecks der Rücksendung einer Empfangsbestätigung bei TCP wird der Zustand der ankommenden Pakete anhand einer zuvor erstellten Prüfsumme kontrolliert. Dieser relativ hohe Aufwand, den der Absender und der Empfänger bei TCP schultern müssen, steigt bei unzureichender Qualität der Netzverbindung und begünstigt Verzögerungen.
UDP (RFC 768) wird für die Übertragung von Daten verwendet, wenn eine automatische Bestätigung durch den Empfangshost nicht notwendig oder gar unerwünscht ist. Bei Multimedia-Streaming kommt es zum Beispiel nicht darauf an, dass alle Pakete ihr Ziel erreichen, sondern dass möglichst schnell überhaupt welche empfangen werden und dass der Client-Computer noch genügend Performance für andere Aufgaben bereitstellen kann. Andernfalls würde das Abspielen einer Datei jederzeit angehalten werden falls ein Datenpaket verloren gehen sollte.
TCP erzeugt einen höheren Netzverkehr als UDP, hat aber den Vorteil, dass entweder die geforderten Daten oder zumindest eine Fehlermeldung beim Empfänger ankommt. Der Vorteil von UDP, nämlich der deutlich sparsamere Umgang mit Netzwerkressourcen, macht sich rasch bei Multimedia-Streaming bezahlt.
Serverseitige Verarbeitung einer Client-Anfrage
Die URL-Anforderung des Clients wird von dem Webserver in mehreren Phasen bearbeitet. Dieser Prozess läuft je nach Typ der Serversoftware etwas unterschiedlich ab, doch das Prinzip ist immer gleich. Der Webserver versucht im ersten Schritt, der angeforderten URL eine konkrete Ressource – entweder eine existierende Datei oder ein „virtuelles“ Dokument – zuzuordnen. Sobald fest steht, um welches Objekt es sich handelt, prüft der Webserver, ob der Client über die entsprechende Zugriffsberechtigung verfügt. Als Kriterium können hier etwa die IP-Adresse des Clients oder der Typ der Anfrage (GET, POST) herangezogen werden. Der Webserver kann den Zugriff erlauben (Rückgabewert: OK), die Anforderung ablehnen (Rückgabewert: FORBIDDEN) oder zusätzliche Funktionen ausführen (Rückgabewert: DECLINED).
Falls der Zugriff des Clients durch den Webserver für zulässig befunden wurde (Rückgabewert: OK) tritt der erste Fall ein. Bevor die Freigabe des Dokumentes erfolgen kann, wird noch gegebenenfalls überprüft, ob benutzerbezogene Zugriffskontrolle auf das geforderte Objekt Anwendung findet. Diese verlangt von dem Benutzer eine korrekte Authentifizierung, die dann beispielsweise u.a. dank der Verwendung von Cookies in seinem Browser als eine Session wahrgenommen wird. Der Webserver hat bei der Freigabe der Daten noch den MIME-Typ der Datei (zum Beispiel audio/aiff oder application/x-rtsp) zu bestimmen. Anhand des MIME-Typs und/oder des Pfades der Resource wird ein Content-Handler festgelegt, der die eigentliche Erstellung der Daten übernimmt. Dieser stellt im Falle einer HTML-Datei das benötigte Dokument aus Puzzles wie der HTML-Header und der Body-Teil (oftmals unter Verwendung von serverseitigen Skriptsprachen wie PHP) zusammen.
Beim Versuch, eine prinzipiell unzulässige Ressource zu lesen, liefert der Webserver sofort eine Fehlermeldung und der Zugriff des Clients wird verhindert. Es tritt also der zweite Fall ein (Rückgabewert: FORBIDDEN).
Im dritten Fall (Rückgabewert: DECLINED) wird der Server versuchen, einen Access-Control-Handler zu finden, der über die Zulässigkeit der Anfrage entscheiden kann. Unter Umständen folgt hier die Weiterleitung der Anfrage an einen anderen Prozess. Auf diese Art und Weise kann man zum Beispiel einen Applikationsserver ansprechen. Dieser kommuniziert dann mit dem Client unter Verwendung von HTML-Vorlagen oder einer (Java-basierten) Benutzeroberfläche seiner eigenen Web-Applikationen und gleicht seine Erkenntnisse mit einer Datenbank ab. Ein weiterer wichtiger Aspekt der Verwendung von Applikationsservern ist die Unterstützung von Load-Balancing (zum Beispiel bei WebObjects). Das Auslagern von rechenintensiven Aufgaben auf zusätzliche Servermaschinen und die Verteilung der Last wird deutlich effizienter.
Schließlich muss das Dokument noch vom Server zum Client übertragen werden. Verknüpfte Dokumente wie externe Skripten, Bilder und Animationen werden nach dem Parsen der Startseite quasi „nachträglich“ angefordert und heruntergeladen. Schrittweise wird die Darstellung auf dem Bildschirm des Client-Computers gerendert. In der Zwischenzeit ist der Webserver mit dem Protokollieren der Zugriffe und seiner Speicherreorganisation beschäftigt. Der Benutzer hat die Zeit mit Warten verbracht.
HTTP/2: asynchrone Verbindungen und paralelle Datenübertragung
Eine professionell aufgebaute Internet-Präsenz stützt sich auf einen „kommunikativen“ Webserver unter Verwendung von HHTP/2, um den Aufbau asynchroner Verbindungen und paralelle Datenübertragung zu ermöglichen. Performancemessungen sind dennoch unverzichtbar, wenn es darum geht, den Optimierungsbedarf aufzudecken und potenzielle Leistungsengpässe vorab zu eliminieren.
Die meist unterschätzte Quelle effizienter und kostengünstiger Optimierungen liegt in der Qualität des verwendeten Datenmaterials. Dank sauber programmiertem HTML 5/CSS/JavaScript und leistungsstarker serverseitiger Skripten, einer effizienten Komprimierung und einer angemessen provisionierten Infrastruktur lassen sich Lade- und Antwortzeiten minimieren. Dank der bedarfsgerechten Provisionierung von IT-Ressourcen im Pay-as-you-go-Modell entfallen kostspielige Investitionen.