In meinem letzten Beitrag beschrieb ich 3 Kernbereiche von WPO. Die Infrastruktur ist dabei der Bereich der Serverlandschaft. In diesem Blog beschreibe ich ihn etwas ausführlicher.
Über Content Delivery Networks
Wäre es nicht gut jemanden zu haben, der unseren Inhalt bereitstellen würde, idealerweise ganz nah bei unseren Kunden? Das ist die Aufgabe von Content Delivery Networks (CDN). Bisher wurden sie nur von großen Firmen mit weltweitem Kundenkreis genutzt. Aber auch lokal begrenzt können sie nützlich sein, da sie üblicherweise über die schnellstmögliche Netzanbindung verfügen und gegebenenfalls sogar IT Kosten senken können. Bilder auf einer anderen (Sub-)Domain anzubieten reduziert den Datentransfer, da weniger Header und Cookies mit jeder Anfrage gesendet werden. Diese Subdomains können auch auf spezialisierte Server verweisen. Ein Beispiel: ein httpd Server kann statische Bilder von einer RAM disk ausliefern, anstelle sie von einem Tomcat bei jedem Aufruf aus einem Archiv auspacken zu lassen. Außerdem können auch öffentliche CDNs wie zum Beispiel Google verwendet werden.
Ein sehr gutes Beispiel ist die Einbindung von JavaScript Bibliotheken von Google. Diese werden nicht nur von einem bestens angebundenen Netz bereitgestellt und kosten keine Serverkapizitäten, sondern sie maximieren auch den Effekt von Caching, da der Cache mit anderen Webseiten geteilt wird und so der Cache sogar bei Erstbesuchern gefüllt sein kann. Eine ausführliche Beschreibung über die Vorteile von Google als CDN hat Dave Ward sehr gut zusammengestellt.
Verteilte Caches sind schnelle Datenbanken
Hosting von statischen Inhalten ist aber nur ein Teil der Infrastruktur. Der andere Teil ist die Anwendung mit ihrer Geschäftslogik. Hier können natürlich keine vorgefertigten Antworten vorgehalten werden, sondern es muss sichergestellt werden, dass Antworten auch dann zügig ausgeliefert werden können wenn tausende Benutzer die Seiten verwenden. Sobald man nicht mehr mit einem einzigen Server auskommt werden die Dinge kompliziert. Dem entgegnet man am besten mit einem einfachen Design. Ein weit verbreitetes Problem in Java Anwendungen ist der pro Node gehaltene Zustand der Session. Die Folge davon ist, dass man Benutzer nicht einfach zwischen Server umschieben kann. Dieses „sticky Session“ genannte Problem wurde durch die Einführung von Replikationsmechanismen, welche den Zustand zwischen Nodes kopieren, bekämpft. Allerdings rate ich davon ab, dieses Verfahren als echte Lösung zu betrachten. Es verursacht eine Reihe von Problemen und kostet viel Zeit und Geld. Der dadurch herausgeholte technische Vorteil reicht aber nicht aus, um wirklich zu skalieren. Es wäre viel besser einen zustandslosen Server zu haben, welcher problemlos dynamisch gestartet oder gestoppt werden kann. Das Problem ist also: wohin mit dem Zustand? Ohne Frage ist Zustand sinnvoll.
Schaut man zurück, so wurde der Zustand in die Session gelegt, da die zentrale Datenquelle, „Datenbank“ genannt, einfach viel zu langsam war und selbst nicht gut skalierbar ist. Nun fordere ich natürlich nicht den Zustand zurück in eine relationale Datenbank zu legen. Nein, ich würde sie sogar ganz aus meiner Architektur entfernen wollen. Zeitgemäße Lösungen für diese Herausforderung liefern sogenannte NoSQL Datenbanken, welche verteilt arbeiten und die Daten als einfache Schlüssel-Werte Paare speichern.
Das klingt erstmal sehr einfach, ist aber sehr mächtig. Viele aktuelle Entwicklungen kommen viel besser ohne eine relationale Datenbank zurecht. Große Java NoSQL Datenbanken sind Hadoop und Cassandra.
Session Informationen können auch einfach im Speicher eines verteilten Speicher caches wie MemCache liegen. Unter nosql-database.org gibt es eine großartige Liste mit diesen Lösungen und Produkten.
Nach diesem etwas längeren Exkurs zurück zum Thema. Es geht darum Anwendungen einfach skalierbar zu machen. Mit Anstieg der Last erreicht man zwangsläufig Grenzen an denen die Software auf vorhandener Hardware nicht länger linear skaliert. In diesen Situationen benötigt man zusätzliche Server. Idealerweise speziell dedizierte Server für API Aufrufe, Webservices oder Geschäftslogik. Server bei Bedarf starten zu können, und das sogar nahe beim Kunden ist der echte Wert der „Cloud“. Dies ist nicht möglich wenn man weiterhin komplizierte Failover und Replikationssysteme verwendet, wie man es heute noch in großen Firmen tut.
Protokolltuning und seine Effekte
Natürlich sollte schnelle Netzwerkausrüstung und Anbindung sowie eine sinnvolle Verteilung der physikalischen Hardware auch bei virtualisierten Umgebungen gegeben sein. Zwar bietet sich hier wenig Potential für Tuning, allerdings haben Firmen wie Google damit begonnen neue Netzwerkprotokolle wie SPDY zu erfinden, eigene, spezialisierte Netzwerkkarten zu bauen und auch die durch RFCs gesetzten Regeln zu dehnen. Ein Beispiel dafür ist das sogenannte „slow-start“ Feature von TCP. Wie viele RFCs, wurde TCP in den frühen Tagen der Netzwerke erfunden und wird weiterhin genutzt. Damals hatten die Clients schlechte Anbindungen an die Server, was zu der Folgerung führte, dass Server vor langsamen Clients beschützt werden müssen (und auch anders herum). Also begann man nur wenig Daten zu senden und erhöhte diese Frequenz langsam sobald sie quittiert wurden. Die Datenmenge welche initial, also ohne Bestätigung, gesendet werden darf, ist im sogenannten initial window in RFC 3390 definiert. Sendet man nun aber mehr Daten kann man einige Roundtrips sparen, da keine Antwort des Clients zur vollständigen Datenübermittlung nötig ist. Durch diese Methode kann man unter 100ms Antwortzeiten gelangen und ermöglicht z.B. ein Sucherlebnis wie Google Instant. Eine gute Einführung in das Thema Slow-Start mit weiterführenden Links findet man in Ben Strong’s Blog über Slow Start (in Englisch).
Dies sind nur ein paar Ideen wie man auf der Infrastrukturseite die Performance von Webseiten optimieren kann. Zwar sind einige Ideen stark von der Anwendung abhängig, andere wie z.B. ein optimiertes Initial Window könnten auch von Hosten ihren Kunden als Premiumdienste angeboten werden. Zwar ist Infrastruktur nicht unser Fokus bei codecentric, trotzdem können wir insbesondere bei dem Entwurf der Anwendungen diese Optionen berücksichtigen und dafür sorgen, dass Anwendungen für eine bestmögliche Performance in der Infrastruktur designt sind. Wir sprechen ausserdem die Sprache von Betrieb und Entwicklung und können so bei der Integration unterstützen. Über die Optionen auf der Anwendungs- und Softwareseite schreibe ich in meinem nächsten Beitrag.
Meine WPO Serie:
- Web Performance Optimierung ist das neue SEO
- Web Performance Optimierung: Die Infrastruktur
- Web Performance Optimierung: Serverseitige Software
- Web Performance Optimierung: Clients
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.