Aus dem DBE-Blog

Ultra-skalierbare Webseiten

Skalierbarkeit und Performance werden gerne in einen Topf geworfen, meinen aber zwei verschiedene Dinge. Performance beschreibt, wie schnell eine einzelne Anfrage beantwortet wird – also die reine Ladezeit, die ein Besucher spürt. Skalierbarkeit beschreibt dagegen, ob eine Website auch dann noch zuverlässig antwortet, wenn statt einer Handvoll Leute plötzlich Zehntausende gleichzeitig zugreifen. Eine wirklich gut gebaute Seite ist beides zugleich: Sie lädt schnell und bedient mehrere 10.000 Anfragen pro Sekunde, ohne in die Knie zu gehen. Doch wie funktioniert das? Was muss man dabei beachten – und warum lohnt sich der ganze Aufwand überhaupt? Genau darum geht es in diesem Artikel.

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. Oft kommen die Besucher welche die TV-Shop gesehen haben am nächsten Tag nicht wieder. Ä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. Diese Software sind oft nicht Performant und erzeugen eine hohe CPU-Last pro Request. Die CPU ist jedoch eine begrenzte Resource. Wir müssen jedoch als erstes unsere Problem-Stellen identifizieren und das ist nicht so einfach. Wir sollten erstmal alle wichtigen Messwerte unserer Anwendung protokollieren. Genau das ist die Aufgabe von Monitoring: Werkzeuge wie Zabbix, Prometheus oder Grafana zeichnen rund um die Uhr auf, wie hoch CPU-Last, Arbeitsspeicher, Antwortzeiten und die Zahl gleichzeitiger Verbindungen sind. Alle drei sind quelloffen und kostenlos – man bekommt sie direkt über die jeweilige Projektseite oder über den Paketmanager der Linux-Distribution. Warum der Aufwand? Ohne diese Zahlen optimiert man im Blindflug und "repariert" am Ende gerne Dinge, die gar nicht das eigentliche Problem waren. Der einzige Nachteil: So ein Monitoring will erst einmal eingerichtet und gepflegt werden. Diese Zeit ist aber gut investiert, weil man Engpässe damit oft schon erkennt, bevor sie zum Ausfall führen. monitoing zabbix

Warum sich Performance wirklich lohnt: Google, Conversion und Umsatz

Ein schneller Auftritt ist nicht nur eine Frage des guten Gefühls. Google bewertet die Ladegeschwindigkeit seit Jahren offen als Ranking-Faktor – die sogenannten Core Web Vitals fließen direkt in die Platzierung in der Suche ein. Eine langsame Seite landet also weiter unten und bekommt von vornherein weniger Besucher. Mindestens genauso wichtig ist die Conversion: Zahlreiche Studien (unter anderem von Amazon und Google) zeigen, dass schon eine Sekunde mehr Ladezeit die Absprungrate spürbar erhöht und den Umsatz drückt. Wer beim Ansturm zusammenbricht, verliert die teuer eingekauften Besucher gleich doppelt – einmal sofort und einmal, weil viele nicht wiederkommen. Performance-Optimierung ist damit kein technischer Selbstzweck, sondern bares Geld.

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. Im Folgenden gehe ich die wichtigsten Stellschrauben der Reihe nach durch – von den schnell umsetzbaren Maßnahmen ganz oben bis zu den großen Architektur-Entscheidungen weiter unten. Die Reihenfolge ist bewusst gewählt: Man sollte immer mit den günstigen, einfachen Schritten anfangen, bevor man teure Hardware oder Cluster ins Spiel bringt.

1. Browser-Caching & Content-Optimierung

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.

PageSpeed Tools 100 von 100

PageSpeed Tools
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. Es sollte generell gerpüft werden was alles geladen wird und was davon wirklich gebraucht wird.

Dev Tool Ansicht

Chrome: Dev Tools

2. Moderne Bildoptimierung: WebP, AVIF & Lazy Loading

Bilder sind auf den meisten Seiten der mit Abstand größte Datenposten – und damit der dankbarste Hebel. Wofür? Statt klassischer JPG- und PNG-Dateien sollte man die modernen Formate WebP und AVIF ausliefern; sie sind bei gleicher Qualität oft 30 bis 70 % kleiner. Zusätzlich sorgt Lazy Loading (loading="lazy") dafür, dass Bilder erst geladen werden, wenn der Nutzer sie wirklich sieht, und mit responsive Bildern (srcset) bekommt das Handy eine kleinere Datei als der große Monitor. Wo bekomme ich das? Umwandeln lassen sich Bilder kostenlos mit Werkzeugen wie cwebp, Squoosh oder direkt im Build-Prozess; loading="lazy" und srcset sind Standard-HTML und brauchen keine Bibliothek. Vorteil: deutlich weniger zu übertragende Daten, schnellere Ladezeit und ein besserer LCP-Wert. Nachteil: Man muss die Bilder einmalig konvertieren und für sehr alte Browser gegebenenfalls ein klassisches Format als Rückfallebene bereithalten – in der Praxis aber kaum noch ein Thema.

3. Frontend-Performance: weniger und kleinere Dateien

Neben den Bildern entscheidet vor allem der Umgang mit CSS und JavaScript über das Tempo im Browser. Wofür? CSS- und JS-Dateien sollten minifiziert (Leerzeichen und Kommentare entfernt) und sinnvoll gebündelt werden, damit weniger und kleinere Dateien übertragen werden. Das für den ersten Bildaufbau benötigte CSS (Critical CSS) gehört nach oben, der Rest kann nachgeladen werden; JavaScript blockiert den Seitenaufbau nicht mehr, wenn man es mit defer oder async einbindet. Wo bekomme ich das? Die meisten Build-Werkzeuge (etwa esbuild, Vite, webpack oder lessc mit clean-css) erledigen das Minifizieren automatisch. Warum der Aufwand? Google misst die wahrgenommene Geschwindigkeit über die Core Web Vitals (LCP, INP und CLS); genau diese Werte verbessert man hier direkt. Der Nachteil: Zu aggressives Bündeln kann das Caching verschlechtern (eine kleine Änderung macht ein großes Paket ungültig) – hier ist mit Augenmaß zu arbeiten.

4. Komprimierung & moderne Protokolle: Gzip/Brotli, HTTP/2 und HTTP/3

Was über die Leitung geht, sollte komprimiert sein. Wofür? Mit Gzip oder dem moderneren Brotli schrumpfen Textinhalte wie HTML, CSS und JavaScript um 70 % und mehr, bevor sie versendet werden. Auf der Protokoll-Ebene bringen HTTP/2 (viele Dateien parallel über eine Verbindung) und das noch neuere HTTP/3 auf Basis von QUIC spürbar kürzere Ladezeiten, gerade bei wackeligen Mobilfunk-Verbindungen. Wo bekomme ich das? Beides ist kostenlos und steckt bereits in jedem aktuellen Webserver: Gzip/Brotli, HTTP/2 und HTTP/3 lassen sich in Nginx oder Apache mit wenigen Zeilen Konfiguration aktivieren; ein CDN wie Cloudflare schaltet sie sogar von allein dazu. Vorteil: weniger Datenvolumen und weniger Wartezeit – praktisch ohne laufende Kosten. Nachteil: Komprimierung kostet ein wenig CPU (Brotli auf höchster Stufe mehr als Gzip), weshalb man statische Dateien am besten einmalig vorkomprimiert ablegt, statt sie bei jeder Anfrage neu zu packen.

5. Ein performanter Webserver: Nginx oder lighttpd statt Apache

Der nächste wichtige Schritt ist es, einen performanten Webserver einzusetzen, der asynchrone Kommunikation wie z.B. Nginx 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 ich 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. Wo bekommt man das? Beide Server sind Open Source und kosten nichts; auf jeder gängigen Linux-Distribution genügt ein einziger Befehl über den Paketmanager (etwa apt install nginx), um sie einzurichten. Der große Vorteil: Durch ihr ereignisgesteuertes, asynchrones Modell benötigen sie pro Verbindung kaum Arbeitsspeicher und halten deshalb sehr viele gleichzeitige Besucher aus. Der Nachteil: Wer jahrelang Apache mit seinen .htaccess-Dateien gewohnt war, muss umdenken – Nginx kennt keine .htaccess, die Konfiguration liegt zentral und muss nach jeder Änderung neu geladen werden. Dieser einmalige Umstellungsaufwand macht sich aber schnell bezahlt.

6. Hardware: SSD, viel RAM und Server-Caching

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...

7. Load-Balancer, HAProxy & Hochverfügbarkeit

Aber auch die DNS-Einstellungen und gegebenenfalls ein Caching-Proxy sowie ein Load-Balancer müssen in Betracht gezogen werden. Ein Load-Balancer verteilt die eingehenden Anfragen gleichmäßig auf mehrere Server, sodass kein einzelner Rechner zum Flaschenhals wird. Die Optimierung der Datenbank kann durch ein Cluster oder mittels des HAProxy erreicht werden – auch dieser ist quelloffen, kostenlos und gilt seit Jahren als Standard-Werkzeug für das Verteilen von Last. 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.

Author: ^demon

8. Sessions bei horizontaler Skalierung

Sobald mehrere Webserver hinter einem Load-Balancer stehen, taucht ein gern übersehenes Problem auf: die Sessions. Worum geht es? Standardmäßig speichert PHP die Sitzungsdaten (etwa ob ein Nutzer eingeloggt ist) lokal auf einem Server. Verteilt der Load-Balancer die nächste Anfrage desselben Nutzers auf einen anderen Server, ist die Sitzung dort unbekannt – der Nutzer fliegt scheinbar grundlos raus. Die Lösung: entweder "Sticky Sessions", bei denen der Load-Balancer einen Nutzer immer zum selben Server schickt, oder – deutlich sauberer – ein zentraler Session-Speicher, auf den alle Server zugreifen, in der Praxis meist Redis oder eine Datenbank. Vorteil des zentralen Speichers: Jeder Server kann jede Anfrage beantworten, was echte horizontale Skalierung erst möglich macht. Nachteil: eine zusätzliche Komponente, die selbst hochverfügbar sein sollte – fällt der Session-Speicher aus, sind alle gleichzeitig ausgeloggt.

9. Immer die aktuelle Version der Skriptsprache nutzen

Die Verwendung der jeweils aktuellsten Skriptsprache (PHP, Ruby,...) 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. Warum sich ein Update fast immer lohnt: Ein Sprung von einer alten auf eine aktuelle PHP-Version bringt je nach Anwendung 30 bis 100 % mehr Tempo – und das praktisch geschenkt, ohne eine einzige Zeile am eigenen Code zu ändern. Das aktuelle PHP gibt es kostenlos auf php.net. Der einzige Haken: Sehr alte Anwendungen oder veraltete Plugins laufen unter Umständen nicht mehr fehlerfrei, deshalb sollte man ein Update vorher immer auf einem Test-System ausprobieren.

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

10. OPcache & PHP-FPM richtig einstellen

Eine aktuelle PHP-Version allein reicht nicht – man muss sie auch richtig konfigurieren. Wofür? Der OPcache hält den bereits übersetzten PHP-Code (den Bytecode) im Arbeitsspeicher vor, sodass PHP die Skripte nicht bei jeder Anfrage neu einlesen und kompilieren muss. Das allein bringt häufig 2- bis 3-mal mehr Tempo. Ergänzend lässt sich über PHP-FPM steuern, wie viele Worker-Prozesse gleichzeitig arbeiten dürfen – zu wenige bremsen, zu viele bringen den Server bei einem Ansturm ins Schwitzen. Wo bekomme ich das? OPcache ist seit PHP 5.5 fester Bestandteil und muss nur in der php.ini aktiviert werden; PHP-FPM gehört bei jeder gängigen Installation dazu. Beides kostet nichts. Vorteil: ein riesiger Geschwindigkeitsgewinn ohne jede Code-Änderung. Nachteil: Nach jedem Deployment muss der OPcache geleert werden, sonst läuft unter Umständen noch der alte Code – ein klassischer Stolperstein, den man einmal im Ablauf berücksichtigen muss.

11. Statische Seiten statt dynamischer Generierung

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.

12. Cache-Systeme (Varnish, WP Rocket & Co.)

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; man bekommt ihn kostenlos unter varnish-cache.org. Vorteil: Varnish liefert fertig zwischengespeicherte Seiten direkt aus dem Arbeitsspeicher aus und ist dabei extrem schnell. Nachteil: Die Konfiguration (die sogenannte VCL) hat eine gewisse Einarbeitungszeit, und Inhalte, die sich ständig ändern oder persönlich sind – etwa der Warenkorb – lassen sich nicht ohne Weiteres cachen. Bei den Fertig-Plugins gilt: WP Super Cache ist gratis, das beliebte WP Rocket kostenpflichtig – dafür ist es aber auch ohne tiefes Technikwissen in wenigen Minuten eingerichtet. Auch ein Caching für SQL-Abfragen mit dem ProxySQL ist gewinnbringend.

13. In-Memory-Cache: Redis & Memcached

Die schnellste Datenbank-Abfrage ist die, die gar nicht erst stattfindet. Genau hier setzen In-Memory-Caches wie Redis und Memcached an. Wofür? Sie halten häufig benötigte Daten – Ergebnisse teurer Datenbank-Abfragen, ganze Seitenfragmente, Sessions oder Zähler – direkt im Arbeitsspeicher vor und liefern sie in Sekundenbruchteilen aus, statt die Datenbank zu bemühen. Das entlastet die Datenbank dramatisch und ist oft der entscheidende Schritt von "läuft" zu "skaliert". Wo bekomme ich das? Beide sind quelloffen und kostenlos, in jeder Linux-Distribution paketiert und in praktisch jedem Framework (Laravel, Symfony, WordPress über Plugins) mit wenigen Zeilen angebunden. Redis kann dabei mehr als reines Caching (Listen, Warteschlangen, Pub/Sub), Memcached ist dafür noch eine Spur schlanker. Vorteil: enorme Entlastung von Datenbank und CPU bei minimalem Aufwand. Nachteil: Der Cache lebt im Arbeitsspeicher und ist nach einem Neustart leer; außerdem muss man sich Gedanken machen, wann gespeicherte Daten ungültig werden – ein veralteter Cache ist schlimmer als gar keiner.

14. Content Delivery Network (CDN)

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

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

Zwei der bekanntesten CDNs sind Cloudflare und Cloudfront. Cloudflare bietet sogar einen brauchbaren Gratis-Tarif, Cloudfront gehört zu Amazon Web Services und wird nach Verbrauch abgerechnet. Der Nachteil eines CDN: Man gibt einen Teil der Kontrolle aus der Hand, und das gezielte Leeren des Caches (die sogenannte Invalidierung) nach einer Änderung will gelernt sein – sonst sehen Besucher unter Umständen noch die alte Version einer Seite. 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).

15. Cloud Computing & SaaS

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. Zu den großen Anbietern zählen Amazon Web Services, Microsoft Azure und Google Cloud, in Europa außerdem Hetzner. Der große Vorteil: Man zahlt nur, was man tatsächlich verbraucht, und kann die Leistung bei einem Ansturm binnen Minuten hochfahren. Der Nachteil: Die laufenden Kosten sind schwerer kalkulierbar, und man begibt sich in eine gewisse Abhängigkeit vom Anbieter (Stichwort "Vendor Lock-in"). Auch bei SaaS (Software as a Service), wie z.B. shopify, sollte im Vorfeld geprüft werden ob die Besucherspitzen abfangen können.

16. Payment und E-Mail nicht vergessen

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.

17. Individuell entwickelte Software

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. Der Nachteil liegt auf der Hand: Eine Eigenentwicklung kostet in der Anschaffung mehr und muss langfristig selbst gewartet werden. Wer dagegen ein Standard-System nutzt, bekommt Updates und Sicherheits-Patches gewissermaßen frei Haus. Es ist also eine Abwägung zwischen maximaler Geschwindigkeit auf der einen und Aufwand und Wartung auf der anderen Seite.

18. Reverse-Proxy-Caching mit Nginx

Das ganze kann natürlich auch über einen Proxy-Cache wie NGINX umgesetzt werden. Nginx ist ein leistungsfähiger Reverse-Proxy-Server, der auch als Webserver eingesetzt werden kann. Er verfügt über umfangreiche Caching-Funktionen, die es ermöglichen, häufig angeforderte Inhalte zu speichern und bei Bedarf aus dem Cache zu bedienen, anstatt die Anfrage an PHP weiterzuleiten. Sobald PHP, oder eine andere Skriptsprache zum einsatz kommt wird es unperformant. Beispiel einer Caching-Einstellung:
Proxy Cache

19. Datenbank-Grundlagen: Indizes, EXPLAIN & Read-Replicas

Bevor man die Datenbank mit Proxys und Clustern umstellt, lohnt sich der Blick auf die Grundlagen – denn die Datenbank ist in den allermeisten Fällen der eigentliche Flaschenhals. Indizes sind dabei der größte Hebel: Eine Abfrage, die ohne Index die ganze Tabelle durchsuchen muss, wird mit dem passenden Index oft um den Faktor 100 oder mehr schneller. Wie findet man die Bremsen? Das Slow-Query-Log protokolliert langsame Abfragen, und mit dem Befehl EXPLAIN vor einer Abfrage zeigt die Datenbank, ob sie einen Index nutzt oder die ganze Tabelle liest. Reicht die Optimierung einzelner Abfragen nicht aus, kommen Read-Replicas ins Spiel: Kopien der Datenbank, die alle Lese-Anfragen übernehmen, während nur der Haupt-Server die Schreibvorgänge bekommt. Wo bekomme ich das? Indizes, Slow-Query-Log und EXPLAIN sind in MySQL/MariaDB und PostgreSQL ohne Zusatzsoftware eingebaut; Replikation ist ebenfalls Bordmittel. Vorteil: oft riesiger Effekt bei null Lizenzkosten. Nachteil: Zu viele oder falsche Indizes verlangsamen wiederum das Schreiben, und bei Read-Replicas kann es einen kurzen Moment dauern, bis eine Änderung auf der Kopie ankommt (die sogenannte Replikations-Verzögerung).

20. Datenbank-Caching mit ProxySQL

Das Caching in Verbindung mit einem SQL Proxy wie zum Beispiel ProxySQL ist eine Methode, um die Leistung und Skalierbarkeit von Anwendungen zu verbessern, die auf einer SQL-Datenbank basieren. Ein SQL Proxy fungiert als Vermittler zwischen der Anwendung und der Datenbank und ermöglicht es, Anfragen an die Datenbank zu steuern und zu optimieren. Durch die Kombination von Caching und SQL Proxy können häufig verwendete Daten im Cache gespeichert werden, um den Zugriff auf die Datenbank zu minimieren und die Antwortzeiten zu verbessern. Leiter gibt es für ProxySQL keine GUI, weshalb ich eine mini GUI entwickelt habe: https://github.com/drexlma/proxysql-gui.

Sql Caching

Ein erfolgreiches Caching sieht man auch an den max. gleichzeitigen Request die PHP dann ausführen kann.
Caching PHP

21. Asynchrone Verarbeitung & Queues

Nicht alles muss sofort passieren, während der Nutzer wartet. Wofür? Zeitraubende Aufgaben – E-Mails verschicken, Bilder umrechnen, Rechnungen erzeugen, Daten an Drittsysteme übergeben – lassen sich in eine Warteschlange (Queue) legen und im Hintergrund abarbeiten. Der Nutzer bekommt sofort seine Antwort, die eigentliche Arbeit erledigt ein separater Prozess Sekunden später. Das hält die Anfragen kurz und den Server auch unter Last reaktionsschnell. Wo bekomme ich das? Verbreitete, quelloffene Lösungen sind RabbitMQ, die Queue-Funktionen von Redis oder das schlanke Beanstalkd; die meisten Frameworks bringen dafür bereits eine fertige Anbindung mit. Vorteil: Lastspitzen werden abgefedert, weil die Queue als Puffer wirkt und die Arbeit gleichmäßig verteilt. Nachteil: Die Verarbeitung wird etwas komplexer – man braucht einen Hintergrund-Prozess, der die Queue abarbeitet und überwacht wird, und muss damit umgehen, dass eine Aufgabe auch einmal fehlschlagen und wiederholt werden kann.

Die wichtigsten Tools für Leistungs- und Belastungstests

Wozu das Ganze? Bevor man sich auf eine teure Werbe-Kampagne oder einen TV-Auftritt verlässt, will man wissen, wie viele gleichzeitige Besucher die eigene Seite tatsächlich verträgt – und nicht erst im Ernstfall böse überrascht werden. Genau dazu dienen Lasttest-Werkzeuge: Sie schicken künstlich erzeugten Traffic auf den Server und messen, ab wann die Antwortzeiten steigen oder Fehler auftreten. Hier ein kleiner Auszug an Open-Source-Tools, um die Belastung eines Servers bzw. einer Website zu testen.

Ein typischer Aufruf des weit verbreiteten Apache Benchmark (ab) sieht zum Beispiel so aus: ab -n 1000 -c 100 https://example.com/ – das verschickt 1000 Anfragen mit 100 gleichzeitigen Verbindungen und zeigt anschließend, wie viele Anfragen pro Sekunde der Server geschafft hat. Hier muss bedacht werden, dass diese Tools mit der lokalen Bandbreite begrenzt sind. Hier gibt es noch Leistungstestwerkzeuge die als ein Service angeboten werden. Es gibt jedoch auch externe Anbieter die diese Aufgabe übernehmen. Vor dem Start einer großen Marketing-Kampagne, sollte die Website/Server unbedingt ordentlich getestet werden. Es ist sehr ärgerlich wenn 100.000€ Ausgegeben werden für Werbung und nachher bricht die Website schon nach sehr kurzer Zeit zusammen.
Es gibt einige Anbieter auf dem Markt. Hier eine kleine Auswahl:

LoadView
Flood IO
Loader.io
LoadNinja

Das Projekt anlegen ist sehr einfach gestaltet.
SpeedTest Einstellungen

Es kann eingestellt werden wie die Last auf die Website gesteigert werden soll.

SpeedTest Resultat

Bei der anschließenden Ausführung sieht man schön was die Website und der Server macht.
SpeedTest Resultat

kleiner eigener Code

Hier ein Code welchen ich früher verwendet habe um eine Website zu testen.

#!/bin/bash

# Ziel-URL
URL="xxx"

# Datei, in der die Zeiten gespeichert werden
OUTPUT_FILE="curl_benchmark_alt.txt"

# Datei leeren oder erstellen
echo "" > "$OUTPUT_FILE"

# Schleife von 1 bis 100 gleichzeitige Anfragen
for i in $(seq 1 100); do
    echo "Teste mit $i gleichzeitigen Anfragen..."

    # Starte die Zeitmessung
    START_TIME=$(date +%s.%N)

    # Verwende xargs, um mehrere curl-Prozesse parallel zu starten
    seq 1 $i | xargs -n1 -P$i curl -s -o /dev/null "$URL"

    # Endzeit
    END_TIME=$(date +%s.%N)

    # Berechne die Dauer
    DURATION=$(echo "$END_TIME - $START_TIME" | bc)

    # Ergebnis in die Datei schreiben
    echo "$i Anfragen: $DURATION Sekunden" >> "$OUTPUT_FILE"
done

echo "Fertig! Die Zeiten wurden in $OUTPUT_FILE gespeichert."

Fazit

Dieser Artikel listet die wichtigsten Punkte zur Performance-Optimierung von Websites auf. Wer nicht weiß, wo er anfangen soll, hält sich am besten an diese Reihenfolge: zuerst messen (Monitoring & PageSpeed), dann die einfachen Dinge erledigen (Browser-Caching, Bilder verkleinern, aktuelle PHP-Version), danach den Webserver und ein serverseitiges Cache-System angehen – und erst ganz zum Schluss, wenn das alles ausgereizt ist, über Load-Balancer, Cluster und Cloud nachdenken. Die teuersten Maßnahmen stehen bewusst am Ende, weil sie ohne die Grundlagen davor kaum etwas bringen. 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!

Literatur

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
7. Januar 2022: LastTest Anbieter ergänzt
12. Juli 2023: Caching mit Nginx und ProxySQL
13. Juni 2026: Artikel grundlegend überarbeitet – eigene Abschnitte zu jeder Technologie mit Bezugsquellen, Einsatzzweck sowie Vor- und Nachteilen; Quellenverzeichnis erweitert. Neu hinzugekommen: In-Memory-Cache (Redis/Memcached), OPcache & PHP-FPM, Datenbank-Grundlagen (Indizes, EXPLAIN, Read-Replicas), Bild- und Frontend-Optimierung, Gzip/Brotli sowie HTTP/2 und HTTP/3, Sessions bei horizontaler Skalierung, asynchrone Queues und ein Abschnitt zu SEO und Conversion.