Kim Huebel – Online

Eine kleine Vorwarnung: Der nachfolgende Artikel ist sehr technischer Natur und bisher auch nur theoretisch durchdacht, weil ich die Idee bisher noch nicht umsetzen konnte. Generell geht es mir auch nicht um die Umsetzung an sich – diese dürfte in normalen Hosting-Umgebungen eh flach fallen – es geht mir hier eher um die Grundidee und die Diskussion derselben.

Wer also mit all diesem technischen Kram nichts anfangen kann oder will, dem sei verziehen, wenn er diesen Beitrag nicht liest oder weiterblättert *grins*.

Die Grundproblematik

Worum soll es hier nun genau gehen, wird man sich fragen. Im Grunde ganz einfach, denn das sagt bereits die Überschrift dieses Artikels: “Die Performance einer Website soll erhöht werden”. Was bedeutet dies konkret? Nun, der Seitenaufbau und die Ladezeiten sollen verringert werden und zwar vom Start der Anfrage an bis hin zum fertigen Rendering im Browser.

Wie kann dies erreicht werden? Hier müssen wir das Problem in verschiedene Teilprobleme unterteilen. Ich trenne hier mal zweckmäßigerweise in die folgenden drei Teilbereiche:

1. Generierung des Contents auf dem Server
2. Transport des Contents zum Client
3. Rendering/Darstellung auf dem Client

Damit sehen wir bereits, dass wir hier drei vollkommen unabhängig voneinander optimierbare Gebiete besitzen, die sich wiederum in sich teilweise unterteilen und optimieren lassen. Ich möchte die beiden letzteren Teilbereiche hier nur kurz ansprechen, da hier wohl der geingste Optimierungspotential zu finden sein dürfte.

Die Optimierungsmöglichkeiten

Beim Transport des Contents kann man im Grunde nur dafür Sorge tragen, dass die Netzwerkkomponenten, auf die man selbst Einfluss nehmen kann, entsprechend optimal konfiguriert sind und man das Maximum an Bandbreite, aber auch ein Minimum an Latenzzeiten und Antwortzeiten erreicht hat. Ferner kann man beim Webserver selbst die zu übertragende Datenmenge durch Komprimierung verringern, was dann natürlich auch zu geringeren Transportzeiten führt.

Was die Darstellung auf dem Client angeht, hat man recht wenig Einfluss. Hier gelten die wohl jedem bekannten Regeln, dass man nach Möglichkeit validen Code (zu testen mit dem W3C-Validator) ausliefert und natürlich die darzustellenden Grafiken in ihrer Größe optimiert. Ein Foto, was aus der Digitalkamera kommt ohne Verkleinerung des Bildes selbst ins Web zu stellen, wenn man per HTML-Code die Darstellung auf 320×240 Punkte fixiert hat, ist wohl einer der beliebtesten Fehler, die man in diesem Bereich machen kann. Gott sei Dank bieten viele Content-Management-Systeme hier die Möglichkeit, bei der Einbindung der Grafiken bereits optimierte Größen an Bildern zu verwenden.

Doch kommen wir nun zu den (wie oben angesprochen, eher theoretischen) Dingen, die man auf der Serverseite vornehmen könnte, um vielleicht ein Optimum zu erreichen. Voraussetzung für die Umsetzung dieses Szenarios wäre ohne Frage, dass man komplett die Installation und Konfiguration des Servers selbst in der Hand hat oder auf diese entsprechenden Einfluss nehmen kann.

Wo liegen die “bremsenden Faktoren” beim Server?

Dinge, die einen Server immer belasten, sind Schreib- und Lesezugriffe. Finden diese physikalisch auf den Festplatten statt, ist dies sicherlich ungünstig, denn hier vergeht entsprechende Zeit, bis die Daten endlich im Speicher angekommen sind. Ungünstiger wäre hier noch der Zugriff auf Daten, die auf einem entfernten Rechner liegen (z.B. einem File-Server, der per NFS mit dem Webserver verbunden ist), da hier nicht nur die Zugriffe auf die Festplatte, sondern auch noch die Übertragung per Netzwerk zwischen den Servern zeitlich zu bewerten ist.

Welche Möglichkeit hat man also nun, die Zugriffszeiten für Daten im Dateisystem zu reduzieren? Eine Möglichkeit, die sicherlich auch irgendwie realisierbar ist, wäre, die statischen Dateien dem Webserver in einer RAM-Disk anzubieten. Zugriffe auf eine RAM-Disk sind um ein wesentliches schneller als auf Festplatten. Der Nachteil jedoch: RAM ist flüchtiger Speicher, was bedeutet, dass Daten nach abschalten des Stroms verloren gehen (ebenso beim Reboot). Hier erfordert es also ein gewisses “Management” bei der Datenhaltung. Die Daten müssen also parallel in der RAM-Disk und auf der Festplatte des Rechners gehalten werden (und hier natürlich synchronisiert werden, falls sie sich ändern). Im Grunde ist die Einrichtung einer RAM-Disk und Nutzung dieser in diesem Artikel recht gut beschrieben.

Damit wären also die statischen Webseiten schon mal beschleunigt – Zugriffe auf die Dateien finden nicht mehr auf der Festplatte, sondern in der RAM-Disk statt. Doch was machen wir bei dynamisch generierten Websites?

WordPress z.B. bietet eine Reihe Plugins, die es dazu veranlassen, Datenbankabfragen zu minimieren, indem es z.B. auf statisch hinterlegte Dateien zurückgreift (z.B. WP Super Cache). Für viele Blogs ist diese Lösung sicherlich auch nutzbar (wenn man jetzt noch die erzeugten Dateien in einer RAM-Disk hinterlegt, wird der Server richtg flott!). Problem hierbei ist, dass die hinterlegten Dateien immer nur einen “Schnappschuss” darstellen, der zu einem bestimmten Zeitpunkt gemacht wurde. Dieser Schnappschuss wird z.B. beim WP Super Cache dann erneuert, wenn die zugrunde liegende Seite im WordPress (also ein Artikel oder dergleichen) sich verändert, weil z.B. die Inhalte verändert wurden oder Kommentare dazu kamen. Im Grunde nicht weiter schlimm, jedoch nimmt WP Super Cache hier keine Rücksicht auf die Inhalte von Widgets. Es kann also bei der Nutzung dieses Plugins zu interessanten aber ungewollten “Seiteneffekten” kommen, dass z.B. die gern benutzte “Top 10 Kommentare” bei verschiedenen Seiten verschiedene Ergebnisse liefern, weil eben die Daten von verschiedenen Zeitpunkten stammen. Dieses Verhalten ist sicherlich ein Grund, warum viele dieses Caching der Seiten nicht mögen.

Ein Caching der Webseiten ließe sich im übrigen auch durch Vorschaltung eines Proxys wie z.B. Squid realisieren. Wie dies funktioniert, wurde hier bereits sehr gut dokumentiert, wenn auch eher Typo3 im Vordergrund steht. Natürlich würde ich auch hier dem Squid als Ort, wo er seine erzeugten Caching-Daten hinterlegen wird, eine RAM-Disk an die Hand geben

Was aber auch wichtig sein dürfte für die Performance eines Webservers und die Geschwindigkeit, mit der die Webseiten ausgeliefert werden, ist die Geschwindigkeit der zugrunde liegenden Datenbank bzw. hier konkret: Die Konfiguration des Datenbankservers.

Vielerorts kann man bei den Hostern die Lösung finden, dass die Datenbanken abgetrennt von den Webservern gehalten werden. Dies mag aus sicherheitstechnischer Sicht sicherlich in Ordnung und emfehlenswert sein, jedoch geht dies immer auch ein wenig auf Kosten der Performance – wenn die Server nicht über extrem schnelle Netzwerkverbindungen (Gigabit) miteinander verbunden sind. Häufig liegt hier auch der Grund darin, dass die Webserver in ihrer Ausstattung nicht unbedingt als Datenbankserver geeignet sind, denn wenn ein Datenbankserver eines benötigt, dann ist das viel RAM!

Hat man einen Datenbankserver, der entsprechend ausgestattet ist (also nicht zu wenig RAM), so ist dieser entsprechend zu konfigurieren. Welche Auswirkungen Änderungen bei der MySQL-Konfiguration haben und an welchen Stellschrauben hier wie zu drehen ist, darüber gibt dieser Artikel gute Auskünfte.

Schlusswort

Wie man sieht, habe ich mich bei diesem Beitrag unheimlich in die Nutzung von RAM-Disks verliebt, was sicherlich auch einen nicht von der Hand zu weisenden Vorteil bringen dürfte. Leider ist es jedoch so, dass dieser Trick nur funktioniert, wenn die Hosting-Umgebung hier mitspielt, sprich, man eine RAM-Disk überhaupt einrichten und nutzen kann! Sollte dies nicht der Fall sein, hat man leider an dieser Stelle Pech gehabt.

Man sieht aber auch, dass hinter einem schnellen Server einiges an Erfahrung und Know-How stecken kann.

Verwandte Artikel

• Wie mache ich einen Webserver richtig schnell? (0)
• WP-Tuning und Erweiterung verschiedener Blogs (2)
• Performance-Steigerung bei WordPress (2)
• Wie optimiere ich einen Apache-Webserver? (0)
• Widget in Eigenentwicklung (2)

Empfehle diesen Beitrag via Twitter!