10 Tipps für eine 10-mal höhere Anwendungsleistung

NGINX | 05. Oktober 2015

Die Performance von Webanwendungen zu verbessern, ist wichtiger denn je. Der Anteil der Wirtschaftsaktivitäten, die online stattfinden, wächst; inzwischen entfallen mehr als 5 % der Wirtschaftsleistung der Industrieländer auf das Internet (siehe „Ressourcen zu Internetstatistiken“ weiter unten). Und in unserer modernen, ständig vernetzten und hochgradig verknüpften Welt sind die Erwartungen der Nutzer höher denn je. Wenn Ihre Website nicht sofort reagiert oder Ihre App nicht ohne Verzögerung funktioniert, wechseln die Nutzer schnell zu Ihren Mitbewerbern.

Eine vor fast 10 Jahren von Amazon durchgeführte Studie zeigte beispielsweise, dass bereits damals eine Verkürzung der Seitenladezeit um 100 Millisekunden zu einer Umsatzsteigerung von 1 % führte. Eine weitere aktuelle Studie ergab, dass mehr als die Hälfte der befragten Websitebetreiber angab, aufgrund einer schlechten Anwendungsleistung Umsatzeinbußen oder Kundenverluste erlitten zu haben.

Wie schnell muss eine Website sein? Mit jeder Sekunde, die eine Seite zum Laden benötigt, brechen etwa 4 % der Nutzer den Vorgang ab. Führende E-Commerce-Websites ermöglichen eine erste Interaktion innerhalb von ein bis drei Sekunden und erzielen damit die höchste Konversionsrate. Es ist klar, dass bei der Performance von Webanwendungen viel auf dem Spiel steht – und die Bedeutung dürfte weiter zunehmen.

Die Performance verbessern zu wollen, ist einfach – tatsächlich Ergebnisse zu erzielen, ist jedoch schwierig. Um Sie dabei zu unterstützen, finden Sie in diesem Blogbeitrag zehn Tipps, mit denen Sie die Performance Ihrer Website um das bis zu 10-Fache steigern können. Dies ist der erste Beitrag einer Reihe, in der erläutert wird, wie Sie die Performance Ihrer Anwendung mithilfe bewährter Optimierungstechniken und mit ein wenig Unterstützung von NGINX verbessern können. Außerdem zeigt diese Reihe auf, welche potenziellen Sicherheitsverbesserungen Sie dabei erzielen können.

Tipp 1 – Anwendungen mit einem Reverse-Proxy-Server beschleunigen und absichern

Wenn Ihre Webanwendung auf einem einzelnen Rechner ausgeführt wird, scheint die Lösung für Leistungsprobleme möglicherweise auf der Hand zu liegen: Schaffen Sie einfach einen schnelleren Rechner mit mehr Prozessorleistung, mehr Arbeitsspeicher, einem schnellen Festplatten-Array und so weiter an. Auf dem neuen Rechner können Ihr WordPress-Server, Ihre Node.js-Anwendung, Ihre Java-Anwendung usw. dann schneller als zuvor ausgeführt werden. (Wenn Ihre Anwendung auf einen Datenbankserver zugreift, scheint die Lösung möglicherweise immer noch einfach: Schaffen Sie zwei schnellere Rechner und eine schnellere Verbindung zwischen ihnen an.)

Das Problem ist, dass die Geschwindigkeit des Rechners möglicherweise gar nicht die Ursache ist. Webanwendungen laufen oft langsam, weil der Computer ständig zwischen verschiedenen Aufgaben wechselt: Er interagiert über Tausende von Verbindungen mit Benutzern, greift auf Dateien auf der Festplatte zu und führt Anwendungscode aus. Der Anwendungsserver ist möglicherweise überlastet – der Arbeitsspeicher geht zur Neige, Speicherblöcke werden auf die Festplatte ausgelagert und zahlreiche Anfragen müssen auf den Abschluss einer einzelnen Aufgabe wie etwa eines Festplattenzugriffs warten.

Anstatt Ihre Hardware aufzurüsten, können Sie einen völlig anderen Ansatz verfolgen: Fügen Sie einen Reverse-Proxy-Server hinzu, der einige dieser Aufgaben übernimmt. Ein Reverse-Proxy-Server befindet sich vor dem Rechner, auf dem die Anwendung ausgeführt wird, und verarbeitet den Internetdatenverkehr. Nur der Reverse-Proxy-Server ist direkt mit dem Internet verbunden; die Kommunikation mit den Anwendungsservern erfolgt über ein schnelles internes Netzwerk.

Durch den Einsatz eines Reverse-Proxy-Servers muss der Anwendungsserver nicht mehr darauf warten, dass Benutzer mit der Webanwendung interagieren, und kann sich stattdessen darauf konzentrieren, Seiten zu erstellen, die der Reverse-Proxy-Server über das Internet überträgt. Da der Anwendungsserver nicht mehr auf Antworten der Clients warten muss, kann er Geschwindigkeiten erreichen, die nahezu den in optimierten Benchmarks erzielten Werten entsprechen.

Durch das Hinzufügen eines Reverse-Proxy-Servers wird Ihre Webserver-Konfiguration zudem flexibler. Ist beispielsweise ein Server eines bestimmten Typs überlastet, kann problemlos ein weiterer Server desselben Typs hinzugefügt werden. Fällt ein Server aus, lässt er sich einfach ersetzen.

Aufgrund der damit verbundenen Flexibilität ist ein Reverse-Proxy-Server auch eine Voraussetzung für viele weitere leistungssteigernde Funktionen, wie zum Beispiel:

Lastverteilung (siehe Tipp 2) – Ein Load Balancer wird auf einem Reverse-Proxy-Server ausgeführt, um den Datenverkehr gleichmäßig auf mehrere Anwendungsserver zu verteilen. Mit einem Load Balancer können Sie Anwendungsserver hinzufügen, ohne Ihre Anwendung ändern zu müssen.
Caching statischer Dateien (siehe Tipp 3) – Direkt angeforderte Dateien, wie Bild- oder Codedateien, können auf dem Reverse-Proxy-Server gespeichert und direkt an den Client gesendet werden. Dadurch werden Ressourcen schneller bereitgestellt und der Anwendungsserver entlastet, sodass die Anwendung schneller ausgeführt werden kann.
Absicherung Ihrer Website – Der Reverse-Proxy-Server kann mit hohen Sicherheitsstandards konfiguriert und überwacht werden, um Angriffe schnell zu erkennen und darauf zu reagieren. So bleiben die Anwendungsserver geschützt.

Die NGINX-Software wurde speziell für den Einsatz als Reverse-Proxy-Server entwickelt und bietet zusätzlich die oben beschriebenen Funktionen. NGINX verwendet einen ereignisgesteuerten Verarbeitungsansatz, der effizienter ist als der herkömmlicher Server. NGINX Plus bietet weitere fortschrittliche Reverse-Proxy-Funktionen, beispielsweise Integritätsprüfungen für Anwendungen, spezialisiertes Request-Routing, erweitertes Caching und Support.

Tipp 2 – Einen Load Balancer hinzufügen

Das Hinzufügen eines Load Balancers ist eine relativ einfache Änderung, mit der sich die Leistung und Sicherheit Ihrer Website erheblich verbessern lassen. Anstatt einen zentralen Webserver größer und leistungsfähiger zu machen, verteilen Sie den Datenverkehr mithilfe eines Load Balancers auf mehrere Server. Selbst wenn eine Anwendung schlecht programmiert ist oder Skalierungsprobleme hat, kann ein Load Balancer die Benutzerfreundlichkeit ohne weitere Änderungen verbessern.

Ein Load Balancer ist zunächst einmal ein Reverse-Proxy-Server (siehe Tipp 1) – er empfängt Internetdatenverkehr und leitet Anfragen an einen anderen Server weiter. Das Besondere daran ist, dass der Load Balancer zwei oder mehr Anwendungsserver unterstützt und dabei verschiedene Algorithmen verwendet, um die Anfragen auf die Server zu verteilen. Das einfachste Lastverteilungsverfahren ist Round Robin, bei dem jede neue Anfrage an den jeweils nächsten Server in der Liste gesendet wird. Bei anderen Verfahren werden Anfragen beispielsweise an den Server mit den wenigsten aktiven Verbindungen gesendet. NGINX Plus bietet Funktionen, mit denen eine bestimmte Benutzersitzung auf demselben Server fortgeführt werden kann. Dies wird als Sitzungspersistenz bezeichnet.

Load Balancer können die Leistung erheblich verbessern, da sie verhindern, dass ein Server überlastet wird, während andere Server auf Anfragen warten. Außerdem erleichtern sie die Erweiterung Ihrer Webserver-Kapazität, da Sie relativ kostengünstige Server hinzufügen und sicher sein können, dass diese voll ausgelastet werden.

Zu den Protokollen, für die ein Lastenausgleich durchgeführt werden kann, gehören HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI, SCGI, uwsgi, memcached und verschiedene andere Anwendungstypen, darunter TCP-basierte Anwendungen und andere Layer-4-Protokolle. Analysieren Sie Ihre Webanwendungen, um festzustellen, welche davon Sie verwenden und wo Leistungsengpässe bestehen.

Der bzw. die für den Lastenausgleich verwendeten Server können auch verschiedene andere Aufgaben übernehmen, etwa die SSL-Terminierung, die Unterstützung der clientseitigen Nutzung von HTTP/1.x und HTTP/2 sowie das Caching statischer Dateien.

NGINX wird häufig für den Lastenausgleich eingesetzt. Weitere Informationen finden Sie in unserem E-Book „Fünf Gründe für einen Software-Load-Balancer“. Grundlegende Konfigurationsanweisungen finden Sie unter „Lastenausgleich mit NGINX und NGINX Plus, Teil 1“ und die vollständige Dokumentation im „NGINX Plus-Administratorhandbuch“. NGINX Plus ist unser kommerzielles Produkt und unterstützt speziellere Funktionen für den Lastenausgleich, beispielsweise die Weiterleitung von Anfragen anhand der Serverantwortzeit und den Lastenausgleich für das NTLM-Protokoll von Microsoft.

Tipp 3 – Statische und dynamische Inhalte zwischenspeichern

Caching verbessert die Leistung von Webanwendungen, indem Inhalte schneller an Clients ausgeliefert werden. Dabei können verschiedene Strategien zum Einsatz kommen: die Vorverarbeitung von Inhalten für eine schnelle Bereitstellung bei Bedarf, das Speichern von Inhalten auf schnelleren Geräten, das Speichern von Inhalten näher am Client oder eine Kombination dieser Ansätze.

Es gibt zwei verschiedene Arten des Cachings, die berücksichtigt werden sollten:

Caching statischer Inhalte – Selten geänderte Dateien wie Bilddateien (JPEG, PNG) und Codedateien (CSS, JavaScript) können auf einem Edge-Server gespeichert werden, um sie schnell aus dem Arbeitsspeicher oder vom Datenträger abzurufen.
Caching dynamischer Inhalte – Viele Webanwendungen generieren für jede Seitenanfrage neues HTML. Indem Sie eine Kopie des generierten HTML kurzzeitig zwischenspeichern, können Sie die Gesamtzahl der zu generierenden Seiten drastisch reduzieren und dennoch Inhalte bereitstellen, die aktuell genug sind, um Ihre Anforderungen zu erfüllen.

Wenn eine Seite beispielsweise zehnmal pro Sekunde aufgerufen wird und Sie sie eine Sekunde lang zwischenspeichern, werden 90 % der Seitenanfragen aus dem Cache bedient. Wenn Sie statische Inhalte separat zwischenspeichern, können selbst die neu generierten Versionen der Seite größtenteils aus zwischengespeicherten Inhalten bestehen.

Es gibt drei Haupttechniken zum Zwischenspeichern von Inhalten, die von Webanwendungen generiert werden:

Inhalte näher an die Nutzer bringen – Wird eine Kopie des Inhalts näher am Nutzer vorgehalten, verkürzt sich die Übertragungszeit.
Inhalte auf leistungsfähigere Rechner verschieben – Inhalte können auf einem leistungsfähigeren Rechner gespeichert werden, damit sie schneller abgerufen werden können.
Inhalte von überlasteten Rechnern verlagern – Rechner arbeiten bei einer bestimmten Aufgabe manchmal deutlich langsamer als gemäß ihrer Benchmark-Leistung, weil sie mit anderen Aufgaben beschäftigt sind. Das Zwischenspeichern auf einem anderen Rechner verbessert sowohl die Leistung für zwischengespeicherte als auch für nicht zwischengespeicherte Ressourcen, da der Hostrechner dadurch weniger stark ausgelastet ist.

Caching für Webanwendungen kann von innen – also vom Webanwendungsserver – nach außen implementiert werden. Zunächst wird Caching für dynamische Inhalte eingesetzt, um die Auslastung der Anwendungsserver zu reduzieren. Anschließend wird Caching für statische Inhalte verwendet (einschließlich temporärer Kopien von Inhalten, die andernfalls dynamisch wären), wodurch die Anwendungsserver weiter entlastet werden. Schließlich wird das Caching von den Anwendungsservern auf Rechner verlagert, die schneller und/oder näher am Benutzer sind. Dadurch werden die Anwendungsserver entlastet und die Abruf- und Übertragungszeiten verkürzt.

Durch verbessertes Caching lassen sich Anwendungen enorm beschleunigen. Bei vielen Webseiten machen statische Daten, etwa große Bilddateien, mehr als die Hälfte des Inhalts aus. Ohne Caching kann das Abrufen und Übertragen solcher Daten mehrere Sekunden dauern, bei lokaler Zwischenspeicherung hingegen nur den Bruchteil einer Sekunde.

Als Beispiel dafür, wie Caching in der Praxis eingesetzt wird, verwenden NGINX und NGINX Plus zwei Direktiven, um Caching einzurichten: proxy_cache_path und proxy_cache. Sie legen den Speicherort und die Größe des Caches, die maximale Verweildauer von Dateien im Cache sowie weitere Parameter fest. Mit einer dritten (und recht beliebten) Direktive, proxy_cache_use_stale, können Sie den Cache sogar anweisen, veraltete Inhalte bereitzustellen, wenn der Server, der aktuelle Inhalte liefert, ausgelastet oder nicht verfügbar ist. So erhält der Client zumindest etwas statt gar nichts. Aus Sicht der Benutzer kann dies die Verfügbarkeit Ihrer Website oder Anwendung erheblich verbessern.

NGINX Plus verfügt über erweiterte Caching-Funktionen, darunter Unterstützung für Cache-Bereinigung sowie die Anzeige des Cache-Status auf einem Dashboard zur Überwachung der Live-Aktivitäten.

Weitere Informationen zum Caching mit NGINX finden Sie in der Referenzdokumentation und im NGINX Plus-Administratorhandbuch.

Hinweis: Caching überwindet organisatorische Grenzen zwischen den Personen, die Anwendungen entwickeln, Investitionsentscheidungen treffen und Netzwerke in Echtzeit betreiben. Ausgereifte Caching-Strategien, wie die hier angedeuteten, veranschaulichen den Wert einer DevOps-Perspektive, bei der die Sichtweisen von Anwendungsentwicklung, Architektur und Betrieb zusammengeführt werden, um Ziele hinsichtlich Website-Funktionalität, Reaktionszeit, Sicherheit und Geschäftsergebnissen wie abgeschlossenen Transaktionen oder Verkäufen zu erreichen.

Tipp 4 – Daten komprimieren

Komprimierung bietet ein enormes Potenzial zur Leistungssteigerung. Unter anderem für Fotos (JPEG und PNG), Videos (MPEG‑4) und Musik (MP3) gibt es sorgfältig entwickelte und äußerst effektive Komprimierungsstandards. Jeder dieser Standards reduziert die Dateigröße um den Faktor zehn oder mehr.

Textdaten – einschließlich HTML (das Klartext und HTML-Tags enthält), CSS und Code wie JavaScript – werden häufig unkomprimiert übertragen. Die Komprimierung dieser Daten kann die wahrgenommene Leistung von Webanwendungen überproportional verbessern, insbesondere für Clients mit langsamen oder eingeschränkten Mobilfunkverbindungen.

Das liegt daran, dass Textdaten häufig ausreichen, damit ein Benutzer mit einer Seite interagieren kann, während multimediale Inhalte eher unterstützenden oder dekorativen Zwecken dienen. Durch intelligente Inhaltskomprimierung lässt sich der Bandbreitenbedarf von HTML, Javascript, CSS und anderen textbasierten Inhalten in der Regel um 30 % oder mehr reduzieren, wodurch sich auch die Ladezeit entsprechend verkürzt.

Wenn Sie SSL verwenden, reduziert die Komprimierung die Datenmenge, die SSL-codiert werden muss. Dadurch wird ein Teil der für die Datenkomprimierung benötigten CPU-Zeit ausgeglichen.

Es gibt verschiedene Methoden zur Komprimierung von Textdaten. Ein neuartiges, speziell für Header-Daten angepasstes Textkomprimierungsverfahren in SPDY und HTTP/2 finden Sie beispielsweise in Tipp 6. Als weiteres Beispiel für die Textkomprimierung können Sie die GZIP-Komprimierung in NGINX aktivieren. Nachdem Sie die Textdaten auf Ihren Diensten vorkomprimiert haben, können Sie die komprimierte .gz-Datei mithilfe der Direktive gzip_static direkt bereitstellen.

Tipp 5 – SSL/TLS optimieren

Das Secure-Sockets-Layer-Protokoll (SSL) und sein Nachfolger, das Transport-Layer-Security-Protokoll (TLS), kommen auf immer mehr Websites zum Einsatz. SSL/TLS verschlüsselt die Daten, die von Ursprungsservern an Benutzer übertragen werden, und trägt so zur Verbesserung der Website-Sicherheit bei. Ein möglicher Grund für diesen Trend ist, dass Google das Vorhandensein von SSL/TLS inzwischen als positiven Faktor für das Suchmaschinenranking berücksichtigt.

Trotz der zunehmenden Beliebtheit sind die mit SSL/TLS verbundenen Leistungseinbußen für viele Websites ein Knackpunkt. SSL/TLS verlangsamt die Website-Performance aus zwei Gründen:

Der anfängliche Handshake, der bei jedem Öffnen einer neuen Verbindung zum Erzeugen der Verschlüsselungsschlüssel erforderlich ist. Da Browser mit HTTP/1.x mehrere Verbindungen pro Server aufbauen, vervielfacht sich diese Leistungseinbuße.
Laufender Mehraufwand durch die Verschlüsselung der Daten auf dem Server und deren Entschlüsselung auf dem Client.

Um die Verwendung von SSL/TLS zu fördern, haben die Entwickler von HTTP/2 und SPDY (beschrieben im nächsten Tipp) diese Protokolle so konzipiert, dass Browser pro Browsersitzung nur eine einzige Verbindung benötigen. Dadurch wird eine der beiden Hauptursachen für den SSL-Overhead erheblich reduziert. Doch schon heute lässt sich noch mehr tun, um die Leistung von über SSL/TLS bereitgestellten Anwendungen zu verbessern.

Der Mechanismus zur Optimierung von SSL/TLS unterscheidet sich je nach Webserver. NGINX verwendet beispielsweise OpenSSL auf handelsüblicher Standardhardware, um eine mit dedizierten Hardwarelösungen vergleichbare Leistung zu erzielen. Die SSL-Leistung von NGINX ist umfassend dokumentiert und minimiert den Zeit- und CPU-Aufwand für die SSL/TLS-Ver- und -Entschlüsselung.

Weitere Informationen zu Möglichkeiten, die SSL/TLS-Leistung zu steigern, finden Sie außerdem in diesem Blogbeitrag. Kurz zusammengefasst handelt es sich um folgende Techniken:

Sitzungscaching – Verwendet die Direktive ssl_session_cache, um die Parameter zwischenzuspeichern, die beim Absichern jeder neuen Verbindung mit SSL/TLS verwendet werden.
Sitzungstickets oder -IDs – Diese speichern Informationen zu bestimmten SSL/TLS-Sitzungen in einem Ticket oder einer ID, sodass eine Verbindung ohne erneuten Handshake nahtlos wiederverwendet werden kann.
OCSP-Stapling – Verkürzt die Dauer des Handshakes durch Zwischenspeichern von SSL/TLS-Zertifikatsinformationen.

NGINX und NGINX Plus können für die SSL/TLS-Terminierung eingesetzt werden. Dabei übernehmen sie die Ver- und Entschlüsselung des Client-Datenverkehrs, während die Kommunikation mit anderen Servern im Klartext erfolgt. Informationen zur Konfiguration von NGINX oder NGINX Plus für die SSL/TLS-Terminierung finden Sie in den Anleitungen zu HTTPS-Verbindungen und verschlüsselten TCP-Verbindungen.

Tipp 6 – HTTP/2 oder SPDY implementieren

Bei Websites, die bereits SSL/TLS verwenden, verbessern HTTP/2 und SPDY sehr wahrscheinlich die Leistung, da für die einzelne Verbindung nur ein Handshake erforderlich ist. Bei Websites, die SSL/TLS noch nicht verwenden, gleichen HTTP/2 und SPDY die durch den Umstieg auf SSL/TLS (der normalerweise die Leistung beeinträchtigt) entstehenden Nachteile hinsichtlich der Reaktionsgeschwindigkeit aus.

Google führte SPDY im Jahr 2012 ein, um auf Basis von HTTP/1.x eine höhere Leistung zu erzielen. HTTP/2 ist der kürzlich verabschiedete IETF-Standard, der auf SPDY basiert. SPDY wird weitgehend unterstützt, soll jedoch bald eingestellt und durch HTTP/2 ersetzt werden.

Das Hauptmerkmal von SPDY und HTTP/2 ist die Verwendung einer einzigen Verbindung anstelle mehrerer Verbindungen. Diese einzelne Verbindung wird gemultiplext, sodass sie gleichzeitig Teile mehrerer Anfragen und Antworten übertragen kann.

Durch die optimale Nutzung einer einzigen Verbindung vermeiden diese Protokolle den Aufwand für den Aufbau und die Verwaltung mehrerer Verbindungen, der durch die Implementierung von HTTP/1.x in Browsern entsteht. Die Verwendung einer einzigen Verbindung ist insbesondere bei SSL von Vorteil, da sie die zeitaufwendigen Handshakes minimiert, die SSL/TLS zum Aufbau einer sicheren Verbindung benötigt.

Das SPDY-Protokoll erforderte die Verwendung von SSL/TLS; HTTP/2 setzt sie offiziell nicht voraus, doch bislang verwenden alle Browser mit HTTP/2-Unterstützung das Protokoll nur, wenn SSL/TLS aktiviert ist. Das heißt, ein Browser mit HTTP/2-Unterstützung verwendet das Protokoll nur, wenn die Website SSL nutzt und ihr Server HTTP/2-Datenverkehr akzeptiert. Andernfalls kommuniziert der Browser über HTTP/1.x.

Wenn Sie SPDY oder HTTP/2 implementieren, benötigen Sie typische HTTP-Leistungsoptimierungen wie Domain-Sharding, das Zusammenfassen von Ressourcen und Bild-Sprites nicht mehr. Diese Änderungen vereinfachen Ihren Code und Ihre Bereitstellungen und erleichtern deren Verwaltung. Weitere Informationen zu den durch HTTP/2 bewirkten Änderungen finden Sie in unserem Whitepaper „HTTP/2 für Webanwendungsentwickler“.

Als Beispiel für die Unterstützung dieser Protokolle: NGINX unterstützte SPDY bereits frühzeitig, und die meisten Websites, die heute SPDY verwenden, laufen auf NGINX. NGINX leistet außerdem Pionierarbeit bei der Unterstützung von HTTP/2 und bietet seit September 2015 Unterstützung für HTTP/2 in NGINX Open Source und NGINX Plus.

Wir bei NGINX gehen davon aus, dass die meisten Websites im Laufe der Zeit SSL vollständig aktivieren und auf HTTP/2 umsteigen werden. Dies wird die Sicherheit erhöhen und – sobald neue Optimierungen gefunden und implementiert werden – zu einfacherem, leistungsfähigerem Code führen.

Tipp 7 – Softwareversionen aktualisieren

Eine einfache Möglichkeit, die Anwendungsleistung zu steigern, besteht darin, die Komponenten Ihres Software-Stacks anhand ihres Rufs hinsichtlich Stabilität und Leistung auszuwählen. Da die Entwickler hochwertiger Komponenten zudem in der Regel kontinuierlich an Leistungsverbesserungen und Fehlerbehebungen arbeiten, lohnt es sich, die neueste stabile Softwareversion zu verwenden. Neue Versionen erhalten mehr Aufmerksamkeit von Entwicklern und der Benutzer-Community. Neuere Builds profitieren außerdem von neuen Compiler-Optimierungen, einschließlich der Abstimmung auf neue Hardware.

Neue stabile Versionen sind in der Regel kompatibler und leistungsfähiger als ältere Versionen. Wenn Sie Ihre Software stets auf dem neuesten Stand halten, behalten Sie außerdem leichter den Überblick über Leistungsoptimierungen, Fehlerbehebungen und Sicherheitswarnungen.

Wenn Sie weiterhin ältere Software verwenden, können Sie möglicherweise auch neue Funktionen nicht nutzen. So erfordert beispielsweise das oben beschriebene HTTP/2 derzeit OpenSSL 1.0.1. Ab Mitte 2016 wird für HTTP/2 OpenSSL 1.0.2 erforderlich sein, das im Januar 2015 veröffentlicht wurde.

NGINX-Benutzer können zunächst auf die neueste Version von NGINX oder NGINX Plus umsteigen. Diese bieten neue Funktionen wie Socket-Sharding und Thread-Pools (siehe Tipp 9) und werden beide kontinuierlich hinsichtlich ihrer Leistung optimiert. Sehen Sie sich anschließend die Software in den tieferen Ebenen Ihres Stacks an und aktualisieren Sie sie, wo immer möglich, auf die neueste Version.

Tipp 8 – Linux für mehr Leistung optimieren

Linux ist heute das zugrunde liegende Betriebssystem für die meisten Webserver-Implementierungen. Als Basis Ihrer Infrastruktur bietet Linux daher erhebliches Potenzial zur Leistungssteigerung. Standardmäßig sind viele Linux-Systeme konservativ darauf abgestimmt, nur wenige Ressourcen zu nutzen und eine typische Desktop-Arbeitslast zu bewältigen. Für Webanwendungen ist daher zumindest ein gewisses Maß an Optimierung erforderlich, um die maximale Leistung zu erzielen.

Linux-Optimierungen sind vom jeweiligen Webserver abhängig. Am Beispiel von NGINX finden Sie hier einige wichtige Änderungen, mit denen Sie Linux beschleunigen können:

Backlog-Warteschlange – Wenn Verbindungen ins Stocken zu geraten scheinen, sollten Sie den Wert von net.core.somaxconn, also die maximale Anzahl der Verbindungen, die zur Verarbeitung durch NGINX in die Warteschlange gestellt werden können, erhöhen. Wenn das bestehende Verbindungslimit zu niedrig ist, werden Fehlermeldungen angezeigt. Sie können diesen Parameter schrittweise erhöhen, bis keine Fehlermeldungen mehr auftreten.
Dateideskriptoren – NGINX verwendet für jede Verbindung bis zu zwei Dateideskriptoren. Wenn Ihr System eine große Anzahl von Verbindungen verarbeitet, müssen Sie möglicherweise sys.fs.file_max, den systemweiten Grenzwert für Dateideskriptoren, und nofile, den Grenzwert für Dateideskriptoren pro Benutzer, erhöhen, um die zusätzliche Last zu bewältigen.
Ephemere Ports – Bei der Verwendung als Proxy erstellt NGINX für jeden Upstream-Server temporäre („ephemere“) Ports. Sie können den durch net.ipv4.ip_local_port_range festgelegten Portbereich vergrößern, um die Anzahl der verfügbaren Ports zu erhöhen. Außerdem können Sie mit der Einstellung net.ipv4.tcp_fin_timeout das Zeitlimit verkürzen, nach dessen Ablauf ein inaktiver Port wiederverwendet wird, sodass Ports schneller wieder verfügbar sind.

Für NGINX empfehlen wir den Leitfaden zur Leistungsoptimierung von NGINX, in dem Sie erfahren, wie Sie Ihr Linux-System so optimieren, dass es große Mengen an Netzwerkverkehr mühelos bewältigen kann!

Tipp 9 – Optimieren Sie Ihren Webserver für mehr Leistung

Unabhängig davon, welchen Webserver Sie verwenden, müssen Sie ihn für eine optimale Performance Ihrer Webanwendung konfigurieren. Die folgenden Empfehlungen gelten grundsätzlich für jeden Webserver, die konkreten Einstellungen beziehen sich jedoch auf NGINX. Zu den wichtigsten Optimierungen gehören:

Zugriffsprotokollierung – Anstatt für jede Anfrage sofort einen Protokolleintrag auf die Festplatte zu schreiben, können Sie die Einträge im Arbeitsspeicher puffern und gesammelt auf die Festplatte schreiben. Fügen Sie bei NGINX der Direktive buffer=size den Parameter access_log hinzu, damit Protokolleinträge auf die Festplatte geschrieben werden, sobald der Speicherpuffer voll ist. Wenn Sie zusätzlich den Parameter flush=time angeben, wird der Inhalt des Puffers auch nach Ablauf der festgelegten Zeit auf die Festplatte geschrieben.
Pufferung – Bei der Pufferung wird ein Teil einer Antwort im Arbeitsspeicher vorgehalten, bis der Puffer voll ist. Dadurch kann die Kommunikation mit dem Client effizienter werden. Antworten, die nicht in den Arbeitsspeicher passen, werden auf die Festplatte geschrieben, was die Leistung beeinträchtigen kann. Wenn die NGINX-Pufferung aktiviert ist, verwenden Sie zu ihrer Verwaltung die Direktiven proxy_buffer_size und proxy_buffers.
Client-Keepalives – Keepalive-Verbindungen reduzieren den Overhead, insbesondere bei Verwendung von SSL/TLS. Bei NGINX können Sie die maximale Anzahl der keepalive_requests erhöhen, die ein Client über eine bestimmte Verbindung senden kann. Der Standardwert beträgt 100. Außerdem können Sie den Wert für keepalive_timeout erhöhen, damit die Keepalive-Verbindung länger geöffnet bleibt und nachfolgende Anfragen schneller verarbeitet werden.
Upstream-Keepalives – Auch Upstream-Verbindungen – also Verbindungen zu Anwendungsservern, Datenbankservern usw. – profitieren von Keepalive-Verbindungen. Für Upstream-Verbindungen können Sie keepalive, also die Anzahl der inaktiven Keepalive-Verbindungen, die für jeden Worker-Prozess geöffnet bleiben, erhöhen. Dadurch können Verbindungen häufiger wiederverwendet werden, sodass weniger neue Verbindungen aufgebaut werden müssen. Weitere Informationen finden Sie in unserem Blogbeitrag HTTP-Keepalive-Verbindungen und Web-Performance.
Begrenzungen – Die Begrenzung der von Clients genutzten Ressourcen kann die Leistung und Sicherheit verbessern. Bei NGINX beschränken die Direktiven limit_conn und limit_conn_zone die Anzahl der Verbindungen von einer bestimmten Quelle, während limit_rate die Bandbreite begrenzt. Diese Einstellungen können verhindern, dass ein legitimer Benutzer übermäßig viele Ressourcen beansprucht, und tragen außerdem zum Schutz vor Angriffen bei. Die Direktiven limit_req und limit_req_zone begrenzen Clientanfragen. Verwenden Sie für Verbindungen zu Upstream-Servern den Parameter max_conns der Direktive server in einem upstream-Konfigurationsblock. Dadurch wird die Anzahl der Verbindungen zu einem Upstream-Server begrenzt und eine Überlastung verhindert. Die zugehörige Direktive queue erstellt eine Warteschlange, in der eine festgelegte Anzahl von Anfragen für einen bestimmten Zeitraum vorgehalten wird, nachdem der Grenzwert von max_conns erreicht wurde.
Worker-Prozesse – Worker-Prozesse sind für die Verarbeitung von Anfragen zuständig. NGINX verwendet ein ereignisbasiertes Modell und betriebssystemabhängige Mechanismen, um Anfragen effizient auf die Worker-Prozesse zu verteilen. Es wird empfohlen, den Wert von worker_processes auf einen Prozess pro CPU festzulegen. Die maximale Anzahl der worker_connections (standardmäßig 512) kann bei Bedarf auf den meisten Systemen problemlos erhöht werden. Experimentieren Sie, um den für Ihr System optimalen Wert zu ermitteln.
Socket-Sharding – In der Regel verteilt ein einzelner Socket-Listener neue Verbindungen auf alle Worker-Prozesse. Beim Socket-Sharding wird für jeden Worker-Prozess ein eigener Socket-Listener erstellt, wobei der Kernel die Verbindungen den jeweils verfügbaren Socket-Listenern zuweist. Dadurch können Sperrkonflikte reduziert und die Leistung auf Mehrkernsystemen verbessert werden. Um Socket-Sharding zu aktivieren, fügen Sie der Direktive reuseport den Parameter listen hinzu.
Threadpools – Jeder Computerprozess kann durch einen einzelnen langsamen Vorgang aufgehalten werden. Bei Webserver-Software kann ein Festplattenzugriff viele schnellere Vorgänge verzögern, etwa das Berechnen oder Kopieren von Informationen im Arbeitsspeicher. Bei Verwendung eines Threadpools wird der langsame Vorgang einer separaten Gruppe von Tasks zugewiesen, während die Hauptverarbeitungsschleife weiterhin schnellere Vorgänge ausführt. Nach Abschluss des Festplattenvorgangs werden die Ergebnisse an die Hauptverarbeitungsschleife zurückgegeben. In NGINX werden zwei Vorgänge – der Systemaufruf read() und sendfile() – an Threadpools ausgelagert.

Thread-Pools tragen zur Steigerung der Anwendungsleistung bei, indem sie langsame Vorgänge einer separaten Gruppe von Tasks zuweisen.

Tipp. Wenn Sie Einstellungen eines Betriebssystems oder unterstützenden Dienstes ändern, ändern Sie jeweils nur eine Einstellung und testen Sie anschließend die Leistung. Wenn die Änderung Probleme verursacht oder Ihre Website dadurch nicht schneller wird, machen Sie sie rückgängig.

Weitere Informationen zur Optimierung eines NGINX-Webservers finden Sie in unserem Blogbeitrag „NGINX für optimale Leistung konfigurieren“.

Tipp 10 – Live-Aktivitäten überwachen, um Probleme und Engpässe zu beheben

Der Schlüssel zu einem leistungsstarken Ansatz bei der Anwendungsentwicklung und -bereitstellung liegt darin, die tatsächliche Leistung Ihrer Anwendung genau und in Echtzeit zu beobachten. Sie müssen in der Lage sein, Aktivitäten auf bestimmten Geräten sowie in Ihrer gesamten Webinfrastruktur zu überwachen.

Die Überwachung der Website-Aktivitäten erfolgt größtenteils passiv – sie zeigt Ihnen, was vor sich geht, überlässt es jedoch Ihnen, Probleme zu erkennen und zu beheben.

Durch die Überwachung lassen sich verschiedene Arten von Problemen erkennen. Dazu gehören:

Ein Server ist ausgefallen.
Ein Server läuft nur eingeschränkt und verliert Verbindungen.
Bei einem Server tritt ein hoher Anteil an Cache-Fehlzugriffen auf.
Ein Server sendet nicht die richtigen Inhalte.

Ein globales Tool zur Überwachung der Anwendungsleistung wie New Relic oder Dynatrace hilft Ihnen, die Seitenladezeit von entfernten Standorten aus zu überwachen, während NGINX Sie bei der Überwachung der Anwendungsbereitstellung unterstützt. Anhand der Daten zur Anwendungsleistung erkennen Sie, wann Ihre Optimierungen für Ihre Benutzer tatsächlich einen Unterschied machen und wann Sie die Kapazität Ihrer Infrastruktur erweitern sollten, um das Datenverkehrsaufkommen zu bewältigen.

Um Probleme schnell erkennen und beheben zu können, bietet NGINX Plus anwendungsbezogene Zustandsprüfungen – synthetische Transaktionen, die regelmäßig wiederholt werden und Sie auf Probleme aufmerksam machen. NGINX Plus bietet außerdem Session Draining. Dabei werden neue Verbindungen unterbunden, während bestehende Aufgaben abgeschlossen werden. Hinzu kommt eine Slow-Start-Funktion, mit der ein wiederhergestellter Server innerhalb einer Gruppe mit Lastverteilung schrittweise wieder seine volle Leistung erreicht. Bei effektivem Einsatz können Sie mithilfe von Zustandsprüfungen Probleme erkennen, bevor sie die Benutzererfahrung erheblich beeinträchtigen. Session Draining und Slow Start ermöglichen es Ihnen zugleich, Server auszutauschen und sicherzustellen, dass sich dieser Vorgang nicht negativ auf die wahrgenommene Leistung oder Verfügbarkeit auswirkt. Die Abbildung zeigt das integrierte NGINX Plus-Dashboard zur Überwachung der Live-Aktivitäten einer Webinfrastruktur mit Servern, TCP-Verbindungen und Caching.

Fazit – 10-fache Leistungssteigerung

Die möglichen Leistungsverbesserungen unterscheiden sich je nach Webanwendung erheblich. Die tatsächlich erzielten Verbesserungen hängen von Ihrem Budget, der Zeit, die Sie investieren können, und den Schwachstellen Ihrer bestehenden Implementierung ab. Wie können Sie also die Leistung Ihrer eigenen Anwendungen um das Zehnfache steigern?

Damit Sie die potenziellen Auswirkungen der einzelnen Optimierungen besser einschätzen können, finden Sie hier Hinweise darauf, welche Verbesserungen mit den oben beschriebenen Tipps jeweils möglich sind – wobei die tatsächlichen Ergebnisse mit ziemlicher Sicherheit variieren werden:

Reverse-Proxy-Server und Lastverteilung – Eine fehlende oder unzureichende Lastverteilung kann zeitweise zu einer sehr schlechten Performance führen. Durch das Hinzufügen eines Reverse-Proxy-Servers wie NGINX lässt sich verhindern, dass Webanwendungen ständig Daten zwischen Arbeitsspeicher und Festplatte hin- und herschieben. Die Lastverteilung kann die Verarbeitung von überlasteten auf verfügbare Server verlagern und erleichtert die Skalierung. Diese Änderungen können die Performance erheblich steigern: Im Vergleich zu den schlechtesten Phasen Ihrer aktuellen Implementierung lässt sich ohne Weiteres eine zehnfache Verbesserung erzielen; auch die Gesamtperformance kann in geringerem, aber dennoch beträchtlichem Maße verbessert werden.
Dynamische und statische Inhalte zwischenspeichern – Wenn Ihr überlasteter Webserver gleichzeitig als Anwendungsserver dient, lässt sich allein durch das Zwischenspeichern dynamischer Inhalte die Leistung zu Spitzenzeiten um das Zehnfache steigern. Auch das Zwischenspeichern statischer Dateien kann die Leistung um ein einstelliges Vielfaches verbessern.
Datenkomprimierung – Die Verwendung von Komprimierungsformaten wie JPEG für Fotos, PNG für Grafiken, MPEG‑4 für Filme und MP3 für Musikdateien kann die Leistung erheblich verbessern. Wenn diese Formate bereits durchgängig eingesetzt werden, kann die zusätzliche Komprimierung von Textdaten (Code und HTML) die anfänglichen Seitenladezeiten halbieren.
SSL/TLS optimieren – Sichere Handshakes können die Leistung erheblich beeinträchtigen. Ihre Optimierung kann daher die anfängliche Reaktionsgeschwindigkeit möglicherweise verdoppeln, insbesondere bei textlastigen Websites. Die Optimierung der Übertragung von Mediendateien über SSL/TLS dürfte hingegen nur geringfügige Leistungsverbesserungen bringen.
Implementierung von HTTP/2 und SPDY – In Verbindung mit SSL/TLS dürften diese Protokolle die Gesamtleistung der Website schrittweise verbessern.
Optimierung von Linux und Webserver-Software (wie NGINX) – Maßnahmen wie die Optimierung der Pufferung, die Verwendung von Keepalive-Verbindungen und die Auslagerung zeitintensiver Aufgaben in einen separaten Thread-Pool können die Leistung erheblich steigern. Thread-Pools können beispielsweise festplattenintensive Aufgaben um nahezu eine Größenordnung beschleunigen.

Wir hoffen, dass Sie diese Techniken selbst ausprobieren. Wir würden gerne erfahren, welche Verbesserungen der Anwendungsleistung Sie damit erzielen können. Teilen Sie Ihre Ergebnisse unten in den Kommentaren oder twittern Sie Ihre Erfahrungen mit den Hashtags #NGINX und #webperf!