7Minuten Lesezeit

Ultra-skalierbare Webseiten

Skalierbare Webseiten/Performante Website zeichnen sich dadurch aus, dass sie mehrere 10.000 Anfragen pro Sekunde problemlos bedienen können. Doch wie funktioniert das? Was muss dabei beachtet werden?

Wie kommt es zu solch einem Besucheransturm?

Spätestens seit im Fernsehen die Serie „Höhle der Löwen“ (VOX) ausgestrahlt wird, geschieht es regelmäßig, dass die Webseiten der Kandidaten dem hohen Besucher-Ansturm während und nach der entsprechenden Sendung nicht standhalten. Das ist problematisch, da gerade in dieser „heißen Phase“ wichtige Leads generiert und qualifizierte Bestellungen abgewickelt werden können. Ähnliche Szenarien ergeben sich auch nach gut laufenden Werbe-Kampagnen oder einer Erwähnung etwa auf Spiegel- oder heise-online. Durch all diese Vorgänge wird das Interesse einer breiteren Öffentlichkeit geweckt (SlashDot-Effekt).
Die Website muss dann Zugriffszahlen von mehreren 100.000 Nutzern in einer Zeitspanne von 15 Minuten oder länger aushalten.

Wo ist das Problem?

Ein normales Hosting-Paket befindet sich meist auf einem Server, den man mit vielen anderen Kunden teilen muss. Daher reichen Bandbreite und Performance oft für gerade einmal 100 gleichzeitige Besucher aus. Auch die oft als „WebServer“ beworbenen Pakete sind in der Regel nichts anderes als normales Shared Hosting und somit nicht performant.

Wenn man dazu noch eine Standard-Software wie Magento, Shopware, Typo3 oder WordPress nutzt, entstehen weitere Probleme.

Wie bekomme ich eine skalierbare und zugleich performante Website?

Das ist gar nicht so einfach zu beantworten da es sehr viele Stellschrauben gibt, an denen gedreht werden kann. Daher sollte man sich als Laie einen fähigen Systemadministrator und/oder Software-Entwickler suchen, der eine kompetente Analyse und Optimierung der notwendigen Prozesse bieten kann. Auch eine Internetagentur die darauf spezialisiert ist kann genauso gut unterstützen.

Browser-Caching & Content-Optimierung auf allen Ebenen bilden einen wichtigen und relativ „niedrigschwelligen“ ersten Schritt. So kann beispielsweise eine Expire-Zeit definiert werden, Bilder können verkleinert werden, und vieles mehr. Hier bietet das Google-Tool „Google PageSpeed Insights“ gute Hilfestellungen. Darüber hinaus sollten ausschließlich Inhalte geladen werden, die auch wirklich benötigt werden. Beispielsweise laden standardmäßige Worpress-Themes viele Daten nach, die eigentlich gar nicht benötigt werden. Das Selbe gilt für CMS-Plugins, Webserver-Plugins, etc.

PageSpeed Tools 100 von 100 PageSpeed Tools 100 von 100

Der nächste wichtige Schritt ist es, einen performanten Webserver einzusetzen, der asynchrone Kommunikation wie z.B. Ngnix oder lighttpd verwendet, und daher eine deutlich größeren Zahl an Zugriffen bewältigen kann.

Unserer Erfahrung nach ist beispielsweise der Apache Webserver diesen Anforderungen leider nicht gewachsen. Als wir vor einiger Zeit die Betreuung der Website TT-NEWS.de übernahmen, lief im Hintergrund der Apache-Webserver. Pro Woche gab es in der Anfangszeit 10-20 Ausfälle pro Tag wegen Überlastung. Nach der Umstellung auf lighttpd kam es zu keinen weiteren Ausfällen. Ein Vergleich der Zahlen illustriert das Problem: Während der Apache Webserver gerade einmal ca. 300 gleichzeitige Zugriffe aushielt, konnte der lighttpd-Webserver ca. 15.000 gleichzeitige Zugriffe problemlos bewältigen.
Neben dem Einsatz einer SSD und viel RAM ist auf der Hardware-Ebene auch das Server-Caching zu beachten. Je mehr gerenderte Daten im Cache vorgehalten werden können, desto besser ist die Performance der Website. Hier gibt es viele mögliche Einstellungen für den Webserver, für PHP, MySQL, etc… Aber auch die DNS-Einstellungen und gegebenenfalls ein Caching-Proxy sowie ein Load-Balancer müssen in Betracht gezogen werden.

Die Optimierung der Datenbank kann durch ein Cluster oder mittels des HAProxy erreicht werden. Die Anfragen werden dann auf mehrere Server verteilt und auch gecached.

Zu überlegen ist auch, aus Gründen der Ausfall-Sicherheit und Redundanz ein High Availability-Cluster (ggf. inkl. Load-Balancer) aufzubauen. Dieses kann zusätzlich auf 3 verschiedenen Rechenzentren gespiegelt werden. Wird das Cluster für Datenbank und Webserver auf mehrere Rechenzentren verteilt, so können dadurch nicht nur eine höhere Verfügbarkeit und mehr Bandbreite genutzt werden, sondern es kann auch die maximale Anzahl gleichzeitiger Requests erhöht werden. Dies ist neben dem Webserver auch für die Datenbank möglich. Ein großer Nachteil ist, dass dieser Vorgang einerseits sehr kostspielig ist, andererseits jedoch oft nicht längerfristig gewinnbringend funktioniert.

Load-Balancer
Author: ^demon

Die Verwendung der jeweils aktuellsten Skriptsprache bringt – zumindest wenn PHP zum Einsatz kommt – eine deutliche Verbesserung. Wie die unten stehende Grafik zeigt, liegt jedoch auch dann das Limit bei knapp 374 gleichzeitigen Zugriffen. Grundsätzlich ist dieses Limit natürlich von vielen verschiedenen Faktoren bedingt.

Performancesteigerung von PHP 5.6 auf PHP 7. Performancesteigerung von PHP 5.6 auf PHP 7
Quelle: http://www.zend.com/en/resources/php7_infographic

Statische Seiten (.html) sind schneller auszuliefern und belasten den Server deutlich weniger, als dynamische Seiten (.php, .asp, .java,…), die erst aus der Datenbank geladen und gerendert werden müssen. Selbstverständlich können nicht alle Funktionen über statische Seiten abgedeckt werden. Eine mögliche Lösung für in eine Website eingebundene Formulare ist es beispielsweise, diese individuell einzubinden oder über docs.google.com (oder vergleichbare Dienstleistungen) entgegen zu nehmen. Anmeldungen für einen Newsletter können auch direkt per POST an z.b. MailChimp übertragen werden. Bei Server-Fehlern oder nicht mehr vorhandenen Seiten sollten die Standard 400 und 500 Fehlerseiten nicht dynamisch erzeugt werden. Hier sollte am besten ein Kauf-Link vom Amazon gegeben angezeigt werden.

Ein Cache-System ist ebenfalls empfehlenswert, jedoch gibt es hier sehr viele verschiedene Angebote, von denen jedes spezifische Vor- und Nachteile hat. Für WordPress kann z.B. WP-Super-Cache oder WP-Rocket eingesetzt werden. Typo3 und Magento haben ein einfaches Cache-System bereits integriert. Für Magento kann zusätzlich Turpentine mit Varnish verwendet werden. Diese Systeme basieren allerdings alle auf der Skript-Sprache PHP. Das bedeutet wiederum Einbußen im Hinblick auf die Performance der Website, denn eine interpretierte Skriptsprache hat immer eine höhere CPU-Last, als wenn keine Skriptsprache zum Einsatz kommt.
Hier sollte, wenn möglich, auf eine Variante ohne Skript-Sprache zurückgegriffen werden, die z.B. mit einer „rule-based rewriting engine“ umgesetzt werden kann. Der Varnish HTTP Cache ist ebenfalls eine sehr gute Option. Auch ein Caching für SQL-Abfragen mit dem ProxySQL ist gewinnbringend.

Ein Content Delivery Network (CDN) liefert die statischen Inhalte einer Website – beispielsweise Bilder, Javascript- und CSS-Files – aus. Das hat gleich mehrere Vorteile:

  1. Sind Inhalte wie JQuery bereits im Browser-Cache vorhanden, müssen diese nicht jedes Mal neu geladen werden.
  2. Der Server wird nicht belastet.
  3. Eine parallele Übertragung an den Client wird ermöglicht, die nicht die Leitung des Servers belastet.
  4. Cachen von Dynamischen Inhalten welche sich selten ändern.

Zwei der bekanntesten CDNs sind Cloudflare und Cloudfront. Hier muss beachtet werden, das trotz des Cachings von dynamische generierten Seiten auch Seiten existieren die nicht gecached werden können. Dazu gehört unteranderem der Checkout (Bestellen von Produkten).

Neben einem CDN gibt es auch noch die Möglichkeit des Cloud Computings. Dabei kann problemlos, während des Betriebs, Performance über die Cloud hinzugebucht werden. Das bietet (zumindest theoretisch) äußerst attraktive Möglichkeiten, eine große Flexibilität und leistungsstarke Performance. Problematisch ist hier oft, dass die versprochene Verfügbarkeit nicht realisiert werden kann und es daher zu häufigen Ausfällen solcher Systemen kommt. Daher ist die Wahl eines seriösen Anbieters sehr wichtig. Auch bei SaaS (Software as a Service), wie z.B. shopify, sollte im Vorfeld geprüft werden ob die Besucherspitzen abfangen können.

Des Weiteren ist der Einsatz eines stabilen Payment-Systems (z.B. PayPal oder Amazon-Payment), das auch mit hohen Besucher-Zahlen umgehen kann, unabdingbar. Schließlich ist die gesamte Performance-Optimierung einer Website hinfällig, wenn das Payment-System der erhöhten Belastung nicht gewachsen ist.

Ebensowenig darf der E-Mail Versand bei der Überarbeitung der Seite vernachlässigt werden. Allerdings ist unserer Erfahrung nach eine Optimierung in diesem Bereich nur in den seltensten Fällen notwendig, da ein Standard-Postfix problemlos mit einigen 1.000 zu versendenden E-Mails gleichzeitig klarkommt. Sollte allerdings ein Drittanbieter eingesetzt werden, können hier einige Nachbesserungen durchaus anfallen.

Darüber hinaus ist eine individuell entwickelte Software oft schneller, als eine Standard-Software. Das liegt daran, dass ausschließlich der Code zum Einsatz kommt, der auch wirklich später gebraucht wird.

Die wichtigsten Tools für Leistungs- und Belastungstests

Hier ein kleiner Auszug von Open-Source-Tools um die Belastung eines Servers/Website zu testen.

Hier muss bedacht werden das diese Tools mit der lokalen Bandbreite begrenzt sind. Hier gibt es noch Leistungstestwerkzeuge die als ein Service angeboten werden.

Fazit

Dieser Artikel listet die wichtigsten Punkte zur Performance-Optimierung von Websites auf. Aufgrund der Komplexität der Zusammenhänge ist es von besonderer Bedeutung für skalierbare Seiten, dass hier keine Schnellschüsse gemacht und stattdessen lieber ein System gewählt werden sollte, mit dem man Erfahrung hat. Es ist ratsam, unbedingt auf Systemempfehlungen und Erfahrungswerte eines Profis zu vertrauen – anderenfalls besteht die Gefahr, dass die Website ausgerechnet im entscheidenden Moment ihren Dienst quittiert, wie dies drastisch bei einigen Kandidaten der Show „Höhle der Löwen“ zu sehen war. Die Performance der Website ist wichtig!

 

 

Updates

  • 1. Nov 2016: Hinweiß zu MailChimp, CDN-Hinweiß dass das Caching nicht immer greift, Leistungstestwerkzeuge hinzugefügt.
  • 2. Nov 2016: Shopify Hinweis hinzugefügt, Magento-Cache hinzugefügt.
  • 17. Nov 2016: Standard 400 und 500 Fehlerseiten
  • 5. Sep 2017: Fehlerseiten mit Amazon-Link