Obwohl die durchschnittliche Bandbreite, die Anwendern zur Verfügung steht, ebenso wie die Backbones im Internet kontinuierlich wachsen, hat man als Benutzer doch oft das Gefühl, dass alles langsamer wird. Nicht ganz unschuldig daran sind die Betreiber von Websites, die oftmals weder die erforderliche Skalierbarkeit haben noch wie in den frühen Tagen des Web auf die genutzte Bandbreite achten.
Wenn beispielsweise für den Aufbau der Startseite von www.sport1.de 260 kB geladen werden müssen, muss sich niemand über die schwache Performance und die starke Auslastung der Server wundern. Dagegen begnügt sich www.tagesschau.de mit 122 kB und www.search.ch sogar mit 54 kB, während der Aufruf von www.swisscom.ch trotz eines im Vergleich mit anderen Sites dürftigen Informationsangebots auf der Startseite 125 kB übertragener Daten erfordert. Dann muss man sich auch nicht wundern, wenn beispielsweise bei der Website von www.sport1.de samstags kaum einmal ein Zugriff auf den Live-Ticker mit den Zwischenständen und Berichten der Fussball-Bundesliga erfolgreich ist.
Auf der anderen Seite kann man dafür nicht nur die Menge an Daten verantwortlich machen, die heruntergeladen werden muss.
Die Performance von Websites wird durch viele Faktoren beeinflusst. Die Gestaltung der Site ist dabei nur einer von vielen. Und natürlich hat diese einen unmittelbaren Einfluss auf die entstehende Last, weil es einen Unterschied macht, ob 1000 oder 10'000 Benutzer pro Tag nur 54 kB oder 260 kB herunterladen müssen. Bei gleicher Benutzeranzahl variiert die Last um den Faktor 5.
Der erste potentielle Engpass ist dabei vom Betreiber der Site nicht zu beeinflussen. Wenn ein Benutzer von seinem Notebook über das Mobiltelefon mit 9,6 kBit/s oder, beispielsweise bei Verwendung von GPRS, auch mal mit 43,2 kBit/s zugreift, ist die herunterzuladende Datenmenge besonders kritisch. Um dem entgegenzuwirken kann auch ein gutes Design der Site helfen, wie beispielsweise www.wetteronline.de zeigt. Wenn man dort direkt einen Link auf eine Stadt gesetzt hat, braucht es gerade einmal rund 20 kB Daten, um die Wetterinformationen anzuzeigen, auch wenn der vollständige Download dann 110 kB ausmacht. Aber nach den ersten 20 kB kann man schon erfahren, wie das Wetter ist, und den weiteren Download abbrechen. Aber auch bei den heute gängigen ISDN-Verbindungen mit 64 kBit/s Bandbreite sind viele der genannten Sites subjektiv noch zu voluminös - und noch sind DSL und vergleichbar performante Technologien nicht so weit verbreitet, dass sie als Standard vorausgesetzt werden könnten.
Weniger problematisch ist im Regelbetrieb das eigentliche Backbone des Internet, das mittlerweile sehr gut skaliert. Allerdings gibt es durchaus Provider - insbesondere solche mit einem hohen Anteil privater Nutzer mit breitbandigen Verbindungen -, bei denen beispielsweise abends kaum noch etwas geht.
Der nächste Engpass ist zumeist der Webserver. Dieser muss die http-requests verarbeiten und heute in den meisten Fällen Anwendungen aufrufen, die dann die eigentlichen Inhalte bereitstellen. Zwischen dem Benutzer und dem Webserver können ausserdem noch Network Load Balancer oder auch ein Content Distribution Network wie Akamai stehen.
Der Aufbau dynamischer Seiten kann sich als ausgesprochen kritisch erweisen. Ebenso können aber die Backend-Anwendungen zum Engpass werden. Hier gibt es ebenso viele potentielle Engpässe wie Schichten - von der Webserver-Anwendung über die ASP- oder JSP-Scripts bis hin zu der Implementierung der Business-Logik und dem Zugriff auf Datenbankserver oder andere Backend-Systeme. Probleme können dabei sowohl durch die Auslegung der Hardware als auch die Konfiguration der Software und die Art der Programmierung entstehen.
Ein typischer Ansatz vieler Verantwortlicher für die Beschaffung von Webservern und ergänzender Hardware ist daher, wesentlich mehr Hardware zu beschaffen, als wirklich erforderlich ist. Der grösste Sun-Enterprise-Server ist dann oft gerade recht. Dennoch funktioniert das System meist nicht wie erwartet, weil es eben nicht dieser Server ist, der zum Engpass wird - der Engpass ist immer das schwächste und nicht das stärkste Glied in der Kette. Durch die richtige Auswahl zusammenpassender Glieder lassen sich kostengünstigere und dennoch effizientere Lösungen schaffen.
Die erste Voraussetzung für eine schnelle Bereitstellung der eigenen Website, die man beeinflussen kann, ist die Verbindung zwischen den Webservern und dem Internet. Eine ausreichende Bandbreite der Connection ist hier unverzichtbar. Hosting-Provider können dabei eine Alternative zumindest für den Teil der Informationen sein, der keine komplexe Anwendungslogik erfordert und daher einfach ausgelagert werden kann. Allerdings setzt das eine saubere Planung der Site-Struktur voraus, um Bereiche mit statischen von solchen mit dynamischen Inhalten und dort wiederum die einfache Content-Bereitstellung aus Datenbanken von komplexer Anwendungslogik mit Zugriff auf interne Backend-Systeme trennen zu können.
Eine interessante Option in diesem Zusammenhang sind die Content Distribution Networks (CDNs) wie Akamai oder Digital Island. Ein CDN arbeitet als grosser, verteilter Cache mit unmittelbarer Anbindung an verschiedene Knotenpunkte des Internet. So arbeitet beispielsweise McAfee mit Akamai zusammen, um die Downloads von Viren-Updates effizient abwickeln zu können. Diese werden nicht direkt über McAfee bereitgestellt, sondern eben über Akamai. Benutzer werden dabei mit einem möglichst optimal positionierten Server von Akamai verbunden, der auf die hohe zu erwartende Last ausgelegt ist.
CDNs funktionieren allerdings nur eingeschränkt mit dynamischen Inhalten. Novell bietet bei seinem Internet Caching System (ICS), das mittlerweile auch Eingang in das Produkt iChain gefunden hat, solche Lösungsansätze in Verbindung mit ausgewählten CDNs an, die aber deutliche Anpassungen der Website einschneidende.
Neben den CDNs sind auch Caching Proxies eine wichtige Option. Solche Systeme werden mittlerweile von sehr vielen Herstellern angeboten. Dazu gehören beispielsweise eben Novell mit iChain und Microsoft mit dem ISA-Server (Internet Security and Acceleration Server). Diese Systeme bedienen Anforderungen von Clients soweit wie möglich aus dem Cache, was natürlich ebenfalls nur mit statischen Inhalten funktioniert.
Im Bereich zwischen dem Internet und den eigenen Caching-Proxies und Webservern ist dann insbesondere das Network Load Balancing gefragt. Dafür gibt es sowohl Hardware- als auch Softwarelösungen. Windows 2000 unterstützt das Load Balancing beispielsweise über den integrierten Dienst NLB (Network Load Balancing). Für die optimale Gestaltung von Websites machen aber Hardwarelösungen in aller Regel mehr Sinn.
Ein weiterer potentieller Engpassfaktor in diesem Bereich sind Firewalls. Je komplexer die Sicherheitsüberprüfung ist, desto höher ist auch die entstehende Last. Daher werden komplexere Firewalls typischerweise auch nur zwischen den Webservern und den Anwendungssystemen, die von diesen angesprochen werden, plaziert. Grundlegende Firewall-Funktionen insbesondere im Bereich des Packet Filtering müssen dagegen auch auf den Routern, über die eine Verbindung zum Internet hergestellt wird, installiert werden. Besonders wichtig ist auch die kontinuierliche Verfolgung von Reports über Sicherheitslücken, um die vergleichsweise exponierten Webserver jeweils auf dem aktuellsten Patch- und Konfigurationsstand zu halten.
Bei Webservern gilt es, vor allem auf das Design der Websites zu achten. Wenn eine Site immer erst einmal 80 kB an Flash-Dateien zum Client sendet und, wie schon beobachtet, die Option Skip erst nach dem Laden dieser Datei anbietet, dann führt das zu einer völlig unnötigen Belastung der eigenen Server und Internetverbindungen. Unter dem Aspekt der Performance muss der Sinn solcher Flash-Intros ohnehin in Frage gestellt werden - die Technologie sollte auf Bereiche beschränkt werden, in denen sie vom Benutzer bewusst aktiviert werden kann oder eben auch nicht. Allerdings ist klar, dass die Wünsche des Designers hier oft mit denen der Administratoren kollidieren.
Wie weiter oben schon angedeutet, ist daneben die saubere Trennung von statischen und dynamischen Inhalten und bei diesen wiederum von dynamischem Content und Anwendungen wichtig, um beispielsweise Proxies und CDNs optimal nutzen zu können.
Eine wesentliche Rolle spielt auch die Gestaltung des Content. Die eingangs genannten Beispiele machen deutlich, dass es zwischen der Gestaltung der Site und dem gelieferten Content keine direkte Korrelation gibt. Das wird besonders deutlich, wenn man beispielsweise www.n-tv.de mit www.tagesschau.de vergleicht. Der Informationsgehalt der beiden Sites ist sehr ähnlich. Während die Tagesschau-Site aber mit 122 kB geladen werden kann, ist man bei N-TV schon bei 281 kB. Dabei spielen Grafiken eine Rolle, aber auch die Komplexität der verwendeten Skripts, mit denen die Anzeige auf dem Browser gesteuert wird. Hier sind die Webdesigner gefordert, sich auch wieder mehr über die Last im Internet Gedanken zu machen.
Ein anderer Performance-Killer ist beispielsweise der übermässige Einsatz von SSL, der auf die Situationen beschränkt werden sollte, in denen wirklich kritische Informationen übermittelt werden müssen. Auf der anderen Seite spielt SSL im Zusammenhang mit der Authentifizierung von Anwendern innerhalb geschlossener Benutzergruppen bei E-Business-Anwendungen eine zentrale Rolle. In diesen Situationen muss dann auch die Load-Balancing-Hardware SSL unterstützen - und wird doch nie die Skalierbarkeit nicht-verschlüsselter Verbindungen erreichen.
Neben diesen gestalterischen Herausforderungen spielen aber auch der verwendete Server und seine Konfiguration eine wichtige Rolle für die Performance. Das beginnt bei der Konfiguration des Betriebssystems mit ausreichendem Cache und geht bis hin zur Bandbreitenbeschränkung für einzelne Sites, wenn mehrere Sites auf einem Server gehostet werden. Damit kann verhindert werden, dass eine starke Nutzung einer Site zu Beeinträchtigungen aller anderen Sites auf dem Server führt.
Je nach angebotenen Inhalten macht auch ein vorbeugendes Krisenmanagement Sinn. Wer beispielsweise aktuelle Inhalte anbietet, sollte auch auf ein kurzfristig extrem steigendes Interesse reagieren können. So waren beispielsweise die meisten Nachrichten-Sites am 11. September diesen Jahres zunächst so gut wie überhaupt nicht erreichbar, bevor sie dann von der dynamischen Generierung der Inhalte auf eine statische Struktur gewechselt haben. Solche Wechsel müssen, wenn ein extremer Anstieg des Interesses wahrscheinlich ist, bereits vorab geplant sein.
Schliesslich muss es auch genug leistungsfähige Webserver geben - wobei die Betonung mehr auf "genug" als auf "leistungsfähig" liegt. Der typische Engpass bei Webservern ist der Zugriff auf den Storage und nicht die Prozessorleistung. Performance-Analysen beispielsweise für den Microsoft IIS machen deutlich, dass maximal vier Prozessoren sinnvoll genutzt werden können. Daher sind auch die oben schon erwähnten Network Load Balancer von zentraler Bedeutung, um die Last auf viele Systeme verteilen zu können.
Bei der Auswahl von Content-Management-Systemen muss genau analysiert werden, wie gut diese skalieren. Denn nur dann, wenn die Systeme optimal mit einer grösseren Zahl von Servern zurechtkommen, kann die Site auch mit wachsenden Anforderungen skaliert werden.
Die stärksten Einschränkungen für die Performance stellen dann schliesslich die Backend-Systeme dar. Denn hier sind einerseits die Fehlerquellen am grössten und andererseits auch die Anforderungen am höchsten. Das Bereitstellen von statischen Inhalten ist vergleichsweise trivial. Wenn aber eine Anwendung aufgerufen wird, dann muss die gesamte Kette zwischen dem Webserver und dem Backend-System optimal gestaltet werden.
Das beginnt bei der Auswahl der Schnittstelle, über die der Webserver mit den Anwendungen zusammenarbeitet, und geht bis hin zur Skalierung des Backend-Systems. Besonders kritisch ist in diesem Bereich die Lastverteilung. Microsoft stellt mit seinem Application Center einen Ansatz für die Realisierung von Clustern bereit. Eine Alternative sind beispielsweise Cluster-Systeme auf Basis von Oracle 9i, auf denen neben dem DBMS auch Anwendungen ausgeführt werden. Eine Lastverteilung auf dieser Ebene setzt voraus, dass das Anwendungsdesign auch eine parallele Ausführung zulässt, ohne dass es beispielsweise zu Deadlocks bei Datenquellen oder dem Informationsverlust innerhalb einer Session kommt.
Neben der Anwendungsarchitektur spielt auch die Gestaltung der Komponenten eine wichtige Rolle. Während für die Microsoft-Welt hier insbesondere http://msdn.microsoft.com eine wertvolle Informationsquelle ist, werden für die Optimierung von Java-Anwendungen unter www.javaperformancetuning.com/tips.shtml umfassende Informationen bereitgestellt. Eine optimale Site-Performance kann nur erreicht werden, wenn bei der Planung der Site und der benutzten Anwendungen auf allen Ebenen versucht wird, Flaschenhälse zu vermeiden. Denn eine noch so gute Lastverteilung zwischen Webservern bringt nichts, wenn zu viele Benutzer Informationen beispielsweise aus der Datenbank mit aktuellen Preise anfordern und diese nicht ausreichend schnell reagieren kann. Die Massnahmen in solchen Situationen reichen von der optimierten Neuentwicklung der Business-Logik bis hin zum Aufbau von Data Warehouses, in die Daten aus den Produktivsystemen repliziert werden. Gerade in diesem Bereich entstehen dann aber auch schnell hohe Kosten, wenn die Performance optimal sein soll.
