10 Tipps für eine 10-fache Anwendungsleistung

Die Verbesserung der Leistung von Webanwendungen ist wichtiger denn je. Der Anteil der Online-Wirtschaftsaktivität wächst; in den Industrieländern sind mittlerweile über 5 % der Wirtschaft online (siehe unten „Ressourcen für Internetstatistiken“ ). Und in unserer modernen, ständig aktiven und hypervernetzten Welt sind die Erwartungen der Benutzer höher als je zuvor. Wenn Ihre Site nicht sofort reagiert oder Ihre App nicht ohne Verzögerung funktioniert, wechseln die Benutzer schnell zur Konkurrenz.

So zeigte beispielsweise eine vor fast zehn Jahren von Amazon durchgeführte Studie, dass schon damals eine Verkürzung der Seitenladezeit um 100 Millisekunden zu einer Umsatzsteigerung von 1 % führte. In einer weiteren aktuellen Studie wurde hervorgehoben, dass mehr als die Hälfte der befragten Websitebesitzer angaben, aufgrund der schlechten Anwendungsleistung Umsatz oder Kunden verloren zu haben.

Wie schnell muss eine Website sein? Pro Sekunde, die das Laden einer Seite dauert, brechen etwa 4 % der Nutzer die Seite ab. Top-E-Commerce-Sites bieten eine Zeit bis zur ersten Interaktion von einer bis drei Sekunden, was die höchste Konversionsrate ermöglicht. Es ist klar, dass für die Leistung von Web-Anwendungen viel auf dem Spiel steht und diese wahrscheinlich noch steigen wird.

Die Leistung verbessern zu wollen ist einfach, aber tatsächlich Ergebnisse zu sehen, ist schwierig. Um Sie auf Ihrem Weg zu unterstützen, bietet Ihnen dieser Blogbeitrag zehn Tipps, mit denen Sie die Leistung Ihrer Website um das bis zu Zehnfache steigern können. Dies ist der erste Teil einer Reihe, in der detailliert beschrieben wird, wie Sie die Leistung Ihrer Anwendungen mithilfe einiger bewährter Optimierungstechniken und mit etwas Unterstützung von NGINX steigern können. In dieser Reihe werden auch mögliche Sicherheitsverbesserungen beschrieben, die Sie dabei erzielen können.

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

Wenn Ihre Webanwendung auf einer einzelnen Maschine ausgeführt wird, liegt die Lösung für Leistungsprobleme möglicherweise auf der Hand: Besorgen Sie sich einfach eine schnellere Maschine mit mehr Prozessor, mehr RAM, einem schnelleren Festplatten-Array usw. Dann kann die neue Maschine Ihren WordPress-Server, Ihre Node.js-Anwendung, Ihre Java-Anwendung usw. schneller ausführen als zuvor. (Wenn Ihre Anwendung auf einen Datenbankserver zugreift, scheint die Lösung möglicherweise immer noch einfach: Besorgen Sie sich zwei schnellere Maschinen und eine schnellere Verbindung zwischen ihnen.)

Das Problem ist, dass die Maschinengeschwindigkeit möglicherweise nicht das Problem ist. Web-Anwendungen werden häufig langsam ausgeführt, weil der Computer zwischen verschiedenen Aufgabentypen wechselt: Interaktion mit Benutzern über Tausende von Verbindungen, Zugriff auf Dateien auf der Festplatte und Ausführen von Anwendungscode usw. Der Anwendungsserver ist möglicherweise überlastet – es geht ihm der Arbeitsspeicher aus, er lagert Speicherblöcke auf die Festplatte aus und viele Anfragen warten auf eine einzelne Aufgabe, wie z. B. die Festplatten-E/A.

Anstatt Ihre Hardware zu aktualisieren, können Sie einen ganz anderen Ansatz wählen: Fügen Sie einen Reverse-Proxy-Server hinzu, um einige dieser Aufgaben auszulagern. Ein Reverse-Proxy-Server befindet sich vor der Maschine, auf der die Anwendung ausgeführt wird, und kümmert sich um den Internetverkehr. Lediglich der Reverse-Proxy-Server ist direkt mit dem Internet verbunden; die Kommunikation mit den Anwendungsservern erfolgt über ein schnelles internes Netzwerk.

Durch die Verwendung eines Reverse-Proxy-Servers muss der Anwendungsserver nicht mehr darauf warten, dass Benutzer mit der Web-App interagieren, sondern kann sich auf das Erstellen von Seiten konzentrieren, die der Reverse-Proxy-Server über das Internet senden kann. Der Anwendungsserver, der nicht mehr auf Client-Antworten warten muss, kann mit Geschwindigkeiten laufen, die nahe an die in optimierten Benchmarks erreichten heranreichen.

Durch das Hinzufügen eines Reverse-Proxy-Servers können Sie Ihr Webserver-Setup außerdem flexibler gestalten. Wenn beispielsweise ein Server eines bestimmten Typs überlastet ist, kann problemlos ein anderer Server desselben Typs hinzugefügt werden. Wenn ein Server ausfällt, kann er problemlos ersetzt werden.

Aufgrund der Flexibilität, die er bietet, ist ein Reverse-Proxy-Server auch Voraussetzung für viele andere leistungssteigernde Funktionen, wie zum Beispiel:

• Lastenausgleich (siehe Tipp 2 ) – Auf einem Reverse-Proxy-Server wird ein Lastenausgleich ausgeführt, um den Datenverkehr gleichmäßig auf mehrere Anwendungsserver zu verteilen. Wenn ein Lastenausgleich vorhanden ist, können Sie Anwendungsserver hinzufügen, ohne Ihre Anwendung überhaupt zu ändern.
• Zwischenspeichern statischer Dateien (siehe Tipp 3 ) – Direkt angeforderte Dateien, etwa Bilddateien oder Codedateien, können auf dem Reverse-Proxy-Server gespeichert und direkt an den Client gesendet werden. Dadurch werden die Assets schneller bereitgestellt und der Anwendungsserver entlastet, sodass die Anwendung schneller ausgeführt wird.
• Sicherung Ihrer Site – Der Reverse-Proxy-Server kann für hohe Sicherheit konfiguriert und überwacht werden, um Angriffe schnell zu erkennen und darauf zu reagieren. So bleiben die Anwendungsserver geschützt.

Die NGINX-Software ist speziell für die Verwendung als Reverse-Proxy-Server mit den oben beschriebenen zusätzlichen Funktionen konzipiert. NGINX verwendet einen ereignisgesteuerten Verarbeitungsansatz, der effizienter ist als herkömmliche Server. NGINX Plus fügt erweiterte Reverse-Proxy-Funktionen hinzu, wie z. B. Anwendungsintegritätsprüfungen , spezialisiertes Anforderungsrouting, erweitertes Caching und Support.

Tipp 2: Fügen Sie einen Load Balancer hinzu

Das Hinzufügen eines Lastenausgleichs ist eine relativ einfache Änderung, die die Leistung und Sicherheit Ihrer Site erheblich verbessern kann. Anstatt einen zentralen Webserver größer und leistungsfähiger zu machen, verwenden Sie einen Load Balancer, um den Datenverkehr auf mehrere Server zu verteilen. Selbst wenn eine Anwendung schlecht geschrieben ist oder Skalierungsprobleme aufweist, kann ein Load Balancer das Benutzererlebnis ohne weitere Änderungen verbessern.

Ein Load Balancer ist in erster Linie ein Reverse-Proxy-Server (siehe Tipp 1 ) – er empfängt den Internetverkehr und leitet Anfragen an einen anderen Server weiter. Der Trick besteht darin, dass der Load Balancer zwei oder mehr Anwendungsserver unterstützt und verschiedene Algorithmen verwendet, um die Anforderungen zwischen den Servern aufzuteilen. Der einfachste Ansatz zum Lastenausgleich ist Round Robin, wobei jede neue Anforderung an den nächsten Server auf der Liste gesendet wird. Andere Methoden umfassen das Senden von Anfragen an den Server mit den wenigsten aktiven Verbindungen. NGINX Plus verfügt über die Möglichkeit , eine bestimmte Benutzersitzung auf demselben Server fortzusetzen, was als Sitzungspersistenz bezeichnet wird.

Load Balancer können zu erheblichen Leistungsverbesserungen führen, da sie verhindern, dass ein Server überlastet wird, während andere Server auf Datenverkehr warten. Sie erleichtern außerdem die Erweiterung Ihrer Webserverkapazität, da Sie relativ kostengünstige Server hinzufügen und sicher sein können, dass diese voll ausgelastet werden.

Zu den Protokollen, bei denen ein Lastenausgleich durchgeführt werden kann, gehören HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI , SCGI, uwsgi, memcached und mehrere andere Anwendungstypen, darunter TCP-basierte Anwendungen und andere Layer-4-Protokolle. Analysieren Sie Ihre Webanwendungen, um festzustellen, welche Sie verwenden und wo die Leistung zu wünschen übrig lässt.

Derselbe Server bzw. dieselben Server, die zum Lastenausgleich verwendet werden, können auch verschiedene andere Aufgaben übernehmen, wie etwa SSL-Terminierung, Unterstützung für die Verwendung von HTTP/1. x und HTTP/2 durch Clients und Caching für statische Dateien.

NGINX wird häufig zum Lastenausgleich verwendet. Laden Sie unser E-Book „ Fünf Gründe für die Wahl eines Software Load Balancers“ herunter, um mehr zu erfahren. Grundlegende Konfigurationsanweisungen erhalten Sie im Abschnitt „Load Balancing mit NGINX und NGINX Plus, Teil 1 “ sowie die vollständige Dokumentation im NGINX Plus Admin Guide . NGINX Plus ist unser kommerzielles Produkt und unterstützt spezialisiertere Lastausgleichsfunktionen wie Lastrouting basierend auf der Serverantwortzeit und die Möglichkeit zum Lastausgleich über das NTLM-Protokoll von Microsoft.

Tipp 3 – Statischen und dynamischen Inhalt zwischenspeichern

Durch die Zwischenspeicherung wird die Leistung von Webanwendungen verbessert, indem Inhalte schneller an Clients übermittelt werden. Beim Caching können verschiedene Strategien zum Einsatz kommen: Vorverarbeiten von Inhalten für eine schnelle Bereitstellung bei Bedarf, Speichern von Inhalten auf schnelleren Geräten, Speichern von Inhalten näher am Client oder eine Kombination davon.

Es sind zwei verschiedene Arten der Zwischenspeicherung zu berücksichtigen:

• Zwischenspeichern statischer Inhalte – Sich selten ändernde Dateien, wie etwa Bilddateien (JPEG, PNG) und Codedateien (CSS, JavaScript), können auf einem Edge-Server gespeichert werden, um sie schnell aus dem Speicher oder von der Festplatte abzurufen.
• Zwischenspeichern dynamischer Inhalte – Viele Webanwendungen generieren für jede Seitenanforderung neues HTML. Indem Sie eine Kopie des generierten HTML für einen kurzen Zeitraum zwischenspeichern, können Sie die Gesamtzahl der zu generierenden Seiten drastisch reduzieren und gleichzeitig immer noch Inhalte bereitstellen, die aktuell genug sind, um Ihren Anforderungen zu entsprechen.

Wenn eine Seite beispielsweise 10 Aufrufe pro Sekunde erhält und Sie sie 1 Sekunde lang zwischenspeichern, kommen 90 % der Anfragen für die Seite aus dem Cache. Wenn Sie statische Inhalte separat zwischenspeichern, bestehen selbst die neu generierten Versionen der Seite möglicherweise größtenteils aus zwischengespeicherten Inhalten.

Es gibt drei Haupttechniken zum Zwischenspeichern von von Webanwendungen generierten Inhalten:

• Inhalte näher an den Benutzer bringen – Wenn sich eine Kopie des Inhalts näher am Benutzer befindet, verkürzt sich die Übertragungszeit.
• Verschieben von Inhalten auf schnellere Maschinen – Inhalte können auf einer schnelleren Maschine gespeichert und schneller abgerufen werden.
• Verschieben von Inhalten von überbeanspruchten Maschinen – Manchmal arbeiten Maschinen bei einer bestimmten Aufgabe viel langsamer als ihre Benchmark-Leistung, weil sie mit anderen Aufgaben beschäftigt sind. Durch das Zwischenspeichern auf einem anderen Computer wird die Leistung der zwischengespeicherten und auch der nicht zwischengespeicherten Ressourcen verbessert, da der Hostcomputer weniger überlastet ist.

Das Caching für Webanwendungen kann von innen – vom Web-Anwendungsserver – nach außen implementiert werden. Erstens wird für dynamische Inhalte Caching verwendet, um die Belastung der Anwendungsserver zu verringern. Anschließend wird der Cache für statische Inhalte (einschließlich temporärer Kopien von ansonsten dynamischen Inhalten) genutzt, wodurch die Anwendungsserver noch weiter entlastet werden. Das Caching wird dann von den Anwendungsservern auf Maschinen verlagert, die schneller und/oder näher am Benutzer sind. Dies entlastet die Anwendungsserver und verkürzt die Abruf- und Übertragungszeiten.

Verbessertes Caching kann Anwendungen enorm beschleunigen. Bei vielen Webseiten machen statische Daten, beispielsweise große Bilddateien, mehr als die Hälfte des Inhalts aus. Das Abrufen und Übertragen solcher Daten kann ohne Zwischenspeichern mehrere Sekunden dauern, werden die Daten jedoch lokal zwischengespeichert, dauert es nur Sekundenbruchteile.

Als Beispiel für die praktische Verwendung von Caching verwenden NGINX und NGINX Plus zwei Anweisungen zum Einrichten des Caching : proxy_cache_path und proxy_cache . Sie geben den Cachespeicherort und die Cachegröße, die maximale Zeit, die Dateien im Cache gespeichert werden, und andere Parameter an. Mit einer dritten (und recht beliebten) Anweisung, proxy_cache_use_stale , können Sie den Cache sogar anweisen, veralteten Inhalt bereitzustellen, wenn der Server, der neuen Inhalt bereitstellt, ausgelastet oder ausgefallen ist, sodass dem Client etwas statt nichts zur Verfügung steht. Aus Benutzersicht kann dies die Verfügbarkeit Ihrer Site oder Anwendung erheblich verbessern.

NGINX Plus verfügt über erweiterte Caching-Funktionen , darunter Unterstützung für die Cache-Bereinigung und Visualisierung des Cache-Status auf einem Dashboard zur Live-Aktivitätsüberwachung.

Weitere Informationen zum Caching mit NGINX finden Sie in der Referenzdokumentation und im NGINX Plus Admin Guide .

Notiz : Beim Caching werden die organisatorischen Grenzen zwischen den Personen überschritten, die Anwendungen entwickeln, den Personen, die Entscheidungen über Kapitalinvestitionen treffen, und den Personen, die Netzwerke in Echtzeit betreiben. Ausgefeilte Caching-Strategien wie die hier erwähnten sind ein gutes Beispiel für den Wert einer DevOps-Perspektive , in der die Perspektiven von Anwendungsentwicklern, Architekten und Betriebsmitarbeitern zusammengeführt werden, um Ziele hinsichtlich Site-Funktionalität, Reaktionszeit, Sicherheit und Geschäftsergebnissen (wie abgeschlossenen Transaktionen oder Verkäufen) zu erreichen.

Tipp 4 – Daten komprimieren

Komprimierung kann die Leistung enorm steigern. Es gibt sorgfältig entwickelte und äußerst effektive Komprimierungsstandards unter anderem für Fotos (JPEG und PNG), Videos (MPEG-4) und Musik (MP3). Jeder dieser Standards reduziert die Dateigröße um eine Größenordnung oder mehr.

Textdaten – einschließlich HTML (das sowohl einfachen Text als auch HTML-Tags umfasst), CSS und Code wie JavaScript – werden häufig unkomprimiert übertragen. Das Komprimieren dieser Daten kann sich unverhältnismäßig stark auf die wahrgenommene Leistung der Web-Anwendung auswirken, insbesondere bei Clients mit langsamen oder eingeschränkten mobilen Verbindungen.

Dies liegt daran, dass Textdaten für die Interaktion eines Benutzers mit einer Seite häufig ausreichen, wohingegen Multimediadaten eher unterstützend oder dekorativ sein können. Durch intelligente Inhaltskomprimierung kann der Bandbreitenbedarf von HTML, JavaScript, CSS und anderen textbasierten Inhalten normalerweise um 30 % oder mehr gesenkt werden, was zu einer entsprechenden Verkürzung der Ladezeit führt.

Wenn Sie SSL verwenden, verringert sich durch die Komprimierung die Datenmenge, die SSL-codiert werden muss, wodurch ein Teil der zum Komprimieren der Daten benötigten CPU-Zeit eingespart wird.

Es gibt unterschiedliche Methoden zum Komprimieren von Textdaten. Siehe beispielsweise Tipp 6 für ein neuartiges Textkomprimierungsschema in SPDY und HTTP/2, das speziell für Header-Daten angepasst ist. Als weiteres Beispiel für Textkomprimierung können Sie die GZIP-Komprimierung in NGINX aktivieren . Nachdem Sie die Textdaten in Ihren Diensten vorkomprimiert haben , können Sie die komprimierte .gz- Datei direkt mit der Anweisung gzip_static bereitstellen.

Tipp 5 – SSL/TLS optimieren

Das Secure Sockets Layer-Protokoll ( SSL ) und sein Nachfolger, das Transport Layer Security-Protokoll (TLS), werden auf immer mehr Webseiten verwendet. SSL/TLS verschlüsselt die von den Ursprungsservern an die Benutzer transportierten Daten, um die Site-Sicherheit zu verbessern. Ein Grund für diesen Trend könnte darin liegen, dass Google die Präsenz von SSL/TLS mittlerweile als positiven Einflussfaktor für das Ranking in Suchmaschinen nutzt.

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

1. Der anfängliche Handshake, der zum Festlegen von Verschlüsselungsschlüsseln erforderlich ist, wenn eine neue Verbindung geöffnet wird. Die Art und Weise, wie Browser, die HTTP/1. x verwenden, mehrere Verbindungen pro Server herstellen, vervielfacht diese Trefferquote.
2. Laufender Mehraufwand durch die Verschlüsselung der Daten auf dem Server und die Entschlüsselung auf dem Client.

Um die Verwendung von SSL/TLS zu fördern, haben die Autoren von HTTP/2 und SPDY (beschrieben im nächsten Tipp ) diese Protokolle so konzipiert, dass Browser nur eine Verbindung pro Browsersitzung benötigen. Dadurch wird eine der beiden Hauptquellen des SSL-Overheads erheblich reduziert. Allerdings kann heute noch mehr getan werden, um die Leistung von über SSL/TLS bereitgestellten Anwendungen zu verbessern.

Der Mechanismus zur Optimierung von SSL/TLS variiert je nach Webserver. Beispielsweise verwendet NGINX OpenSSL und läuft auf handelsüblicher Standardhardware, um eine mit dedizierten Hardwarelösungen vergleichbare Leistung bereitzustellen. Die SSL-Leistung von NGINX ist gut dokumentiert und minimiert den Zeit- und CPU-Aufwand bei der Durchführung der SSL/TLS-Verschlüsselung und -Entschlüsselung.

Darüber hinaus finden Sie in diesem Blogbeitrag Einzelheiten zu Möglichkeiten zur Steigerung der SSL/TLS-Leistung. Um es kurz zusammenzufassen:

• Sitzungs-Caching – Verwendet die Direktive „ssl_session_cache“ , um die Parameter zwischenzuspeichern, die beim Sichern 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 reibungslos und ohne erneutes Handshake wiederverwendet werden kann.
• OCSP-Stapling – Reduziert die Handshake-Zeit durch Zwischenspeichern von SSL/TLS-Zertifikatsinformationen.

NGINX und NGINX Plus können für die SSL/TLS-Terminierung verwendet werden – sie übernehmen die Verschlüsselung und Entschlüsselung des Client-Datenverkehrs und kommunizieren gleichzeitig im Klartext mit anderen Servern. Informationen zum Einrichten von NGINX oder NGINX Plus für die SSL/TLS-Terminierung finden Sie in den Anweisungen für HTTPS-Verbindungen und verschlüsselte TCP-Verbindungen .

Tipp 6 – Implementieren Sie HTTP/2 oder SPDY

Bei Sites, die bereits SSL/TLS verwenden, führen HTTP/2 und SPDY höchstwahrscheinlich zu einer Leistungssteigerung, da für die einzelne Verbindung nur ein Handshake erforderlich ist. Für Sites, die SSL/TLS noch nicht verwenden, ist die Umstellung auf SSL/TLS (das normalerweise die Leistung verlangsamt) mit HTTP/2 und SPDY im Hinblick auf die Reaktionsfähigkeit ein Nullsummenspiel.

Google hat SPDY im Jahr 2012 eingeführt, um eine schnellere Leistung auf Basis von HTTP/1. x zu erzielen. HTTP/2 ist der kürzlich genehmigte IETF-Standard, der auf SPDY basiert. SPDY wird weitgehend unterstützt, wird jedoch bald veraltet sein und durch HTTP/2 ersetzt.

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

Indem diese Protokolle das Beste aus einer Verbindung herausholen, vermeiden sie den Aufwand für das Einrichten und Verwalten mehrerer Verbindungen, wie es die Art und Weise erfordert, in der Browser HTTP/1. x implementieren. Die Verwendung einer einzigen Verbindung ist insbesondere bei SSL hilfreich, da hierdurch das zeitaufwändige Handshake-Verfahren minimiert wird, das SSL/TLS zum Einrichten einer sicheren Verbindung benötigt.

Das SPDY-Protokoll erforderte die Verwendung von SSL/TLS; HTTP/2 erfordert dies offiziell nicht, aber alle bisherigen Browser, die HTTP/2 unterstützen, verwenden es nur, wenn SSL/TLS aktiviert ist. Das heißt, ein Browser, der HTTP/2 unterstützt, verwendet es nur, wenn die Website SSL verwendet und ihr Server HTTP/2-Verkehr akzeptiert. Andernfalls kommuniziert der Browser über HTTP/1. x .

Wenn Sie SPDY oder HTTP/2 implementieren, benötigen Sie keine typischen HTTP-Leistungsoptimierungen wie Domänen-Sharding, Ressourcenzusammenführung und Bild-Spriting mehr. Diese Änderungen vereinfachen und erleichtern die Verwaltung Ihres Codes und Ihrer Bereitstellungen. Um mehr über die durch HTTP/2 verursachten Änderungen zu erfahren, lesen Sie unser Whitepaper „HTTP/2 für Web-Anwendungsentwickler“ .

Ein Beispiel für die Unterstützung dieser Protokolle ist, dass NGINX SPDY schon früh unterstützt hat und die meisten Websites , die SPDY heute verwenden, auf NGINX laufen. NGINX ist auch Vorreiter bei der Unterstützung von HTTP/2, mit Unterstützung für HTTP/2 in NGINX Open Source und NGINX Plus seit September 2015.

Wir bei NGINX erwarten, dass die meisten Websites mit der Zeit SSL vollständig aktivieren und zu HTTP/2 wechseln. Dies führt zu erhöhter Sicherheit und – wenn neue Optimierungen gefunden und implementiert werden – zu einfacherem Code mit besserer Leistung.

Tipp 7 – Softwareversionen aktualisieren

Eine einfache Möglichkeit, die Anwendungsleistung zu steigern, besteht darin, Komponenten für Ihren Software-Stack auf der Grundlage ihres Rufs hinsichtlich Stabilität und Leistung auszuwählen. Darüber hinaus lohnt es sich, die neueste stabile Version der Software zu verwenden, da die Entwickler hochwertiger Komponenten im Laufe der Zeit wahrscheinlich an Leistungsverbesserungen arbeiten und Fehler beheben. Neue Versionen erhalten mehr Aufmerksamkeit von Entwicklern und der Benutzer-Community. Neuere Builds profitieren außerdem von neuen Compileroptimierungen, einschließlich der Abstimmung auf neue Hardware.

Stabile neue Versionen sind normalerweise kompatibler und leistungsstärker als ältere Versionen. Darüber hinaus ist es einfacher, über Tuning-Optimierungen, Fehlerbehebungen und Sicherheitswarnungen auf dem Laufenden zu bleiben, wenn Sie über aktuelle Software-Updates informiert sind.

Wenn Sie bei älterer Software bleiben, kann es auch sein, dass Sie die neuen Funktionen nicht nutzen. Beispielsweise erfordert das oben beschriebene HTTP/2 derzeit OpenSSL 1.0.1. Ab Mitte 2016 erfordert HTTP/2 OpenSSL 1.0.2, das im Januar 2015 veröffentlicht wurde.

NGINX-Benutzer können zunächst auf die neueste Version von NGINX oder NGINX Plus umsteigen. Diese enthalten neue Funktionen wie Socket-Sharding und Thread-Pools (siehe Tipp 9 ) und die Leistung beider Versionen wird ständig optimiert. Schauen Sie sich dann die Software weiter unten in Ihrem Stapel an und wechseln Sie, wann immer möglich, zur aktuellsten Version.

Tipp 8 – Linux hinsichtlich Leistung optimieren

Linux ist heute das zugrunde liegende Betriebssystem für die meisten Webserverimplementierungen und bietet als Grundlage Ihrer Infrastruktur erhebliche Möglichkeiten zur Leistungsverbesserung. Viele Linux-Systeme sind standardmäßig konservativ optimiert, um möglichst wenige Ressourcen zu verbrauchen und einer typischen Desktop-Arbeitslast zu entsprechen. Dies bedeutet, dass bei Anwendungsfällen von Webanwendungen zumindest ein gewisses Maß an Optimierung erforderlich ist, um eine maximale Leistung zu erzielen.

Linux-Optimierungen sind Webserver-spezifisch. Am Beispiel von NGINX sind hier einige wichtige Änderungen aufgeführt, die Sie zur Beschleunigung von Linux in Betracht ziehen können:

• Backlog-Warteschlange – Wenn Sie Verbindungen haben, die ins Stocken geraten, sollten Sie net.core.somaxconn erhöhen, die maximale Anzahl von Verbindungen, die in die Warteschlange gestellt werden können und auf die Bearbeitung durch NGINX warten. Wenn das vorhandene Verbindungslimit zu niedrig ist, werden Fehlermeldungen angezeigt. Sie können diesen Parameter schrittweise erhöhen, bis keine Fehlermeldungen mehr angezeigt werden.
• Dateideskriptoren – NGINX verwendet bis zu zwei Dateideskriptoren für jede Verbindung. Wenn Ihr System viele Verbindungen bedient, müssen Sie möglicherweise sys.fs.file_max , den systemweiten Grenzwert für Dateideskriptoren, und nofile , den Benutzergrenzwert für Dateideskriptoren, erhöhen, um die erhöhte Last zu unterstützen.
• Temporäre Ports – Bei Verwendung als Proxy erstellt NGINX temporäre („temporäre“) Ports für jeden Upstream-Server. Sie können den durch net.ipv4.ip_local_port_range festgelegten Bereich der Portwerte vergrößern, um die Anzahl der verfügbaren Ports zu erhöhen. Mit der Einstellung net.ipv4.tcp_fin_timeout können Sie außerdem das Timeout reduzieren, bevor ein inaktiver Port wiederverwendet wird, was einen schnelleren Umschlag ermöglicht.

Für NGINX lesen Sie den Leitfaden zur Leistungsoptimierung von NGINX . Dort erfahren Sie, wie Sie Ihr Linux-System optimieren, sodass es große Mengen an Netzwerkverkehr problemlos bewältigen kann.

Tipp 9 – Optimieren Sie die Leistung Ihres Webservers

Egal welchen Webserver Sie verwenden, Sie müssen ihn auf die Leistung der Webanwendungen optimieren. Die folgenden Empfehlungen gelten grundsätzlich für alle Webserver, es gelten jedoch spezielle Einstellungen für NGINX. Zu den wichtigsten Optimierungen zählen:

• Zugriffsprotokollierung – Anstatt für jede Anforderung sofort einen Protokolleintrag auf die Festplatte zu schreiben, können Sie Einträge im Speicher puffern und sie als Gruppe auf die Festplatte schreiben. Fügen Sie für NGINX den Parameter buffer= size zur access_log- Direktive hinzu, um Protokolleinträge auf die Festplatte zu schreiben, wenn der Speicherpuffer voll ist. Wenn Sie den Parameter „flush= time“ hinzufügen, wird der Pufferinhalt nach der angegebenen Zeit zusätzlich auf die Festplatte geschrieben.
• Pufferung – Durch die Pufferung wird ein Teil einer Antwort im Speicher gehalten, bis der Puffer voll ist. Dies kann die Kommunikation mit dem Client effizienter machen. Antworten, die nicht in den Speicher passen, werden auf die Festplatte geschrieben, was die Leistung beeinträchtigen kann. Wenn die NGINX-Pufferung aktiviert ist, verwenden Sie die Anweisungen proxy_buffer_size und proxy_buffers, um sie zu verwalten.
• Client-Keepalives – Keepalive-Verbindungen reduzieren den Overhead, insbesondere bei Verwendung von SSL/TLS. Bei NGINX können Sie die maximale Anzahl von Keepalive-Requests, die ein Client über eine bestimmte Verbindung stellen kann, vom Standardwert 100 erhöhen. Außerdem können Sie das Keepalive-Timeout erhöhen, damit die Keepalive-Verbindung länger offen bleibt und nachfolgende Anfragen schneller ausgeführt werden.
• Upstream-Keepalives – Upstream-Verbindungen – Verbindungen zu Anwendungsservern, Datenbankservern usw. – profitieren ebenfalls von Keepalive-Verbindungen. Für Upstream-Verbindungen können Sie „Keepalive“ erhöhen, also die Anzahl der inaktiven Keepalive-Verbindungen, die für jeden Arbeitsprozess offen bleiben. Dadurch ist eine häufigere Wiederverwendung von Verbindungen möglich, sodass die Notwendigkeit, ganz neue Verbindungen zu öffnen, sinkt. Weitere Informationen finden Sie in unserem Blogbeitrag „HTTP-Keepalive-Verbindungen und Web-Leistung“ .
• Beschränkungen – Durch die Beschränkung der von Clients genutzten Ressourcen können Leistung und Sicherheit verbessert werden. Bei NGINX beschränken die Anweisungen limit_conn und limit_conn_zone die Anzahl der Verbindungen von einer bestimmten Quelle, während limit_rate die Bandbreite beschränkt. Diese Einstellungen können einen legitimen Benutzer daran hindern, Ressourcen zu „beanspruchen“ und helfen außerdem dabei, Angriffe zu verhindern. Die Anweisungen limit_req und limit_req_zone begrenzen Clientanforderungen. Verwenden Sie für Verbindungen zu Upstream-Servern den Parameter max_conns für die Serverdirektive in einem Upstream -Konfigurationsblock. Dadurch werden die Verbindungen zu einem Upstream-Server begrenzt und eine Überlastung verhindert. Die zugehörige Warteschlangendirektive erstellt eine Warteschlange, die eine bestimmte Anzahl von Anforderungen für einen bestimmten Zeitraum enthält, nachdem das max_conns -Limit erreicht wurde.
• Arbeitsprozesse – Arbeitsprozesse sind für die Verarbeitung von Anfragen verantwortlich. NGINX verwendet ein ereignisbasiertes Modell und betriebssystemabhängige Mechanismen, um Anfragen effizient auf die Arbeitsprozesse zu verteilen. Es wird empfohlen, den Wert der worker_processes auf eins pro CPU festzulegen. Die maximale Anzahl an Worker-Verbindungen (standardmäßig 512) kann auf den meisten Systemen bei Bedarf problemlos erhöht werden. Experimentieren Sie, um den Wert zu finden, der für Ihr System am besten geeignet ist.
• Socket-Sharding – Normalerweise verteilt ein einzelner Socket-Listener neue Verbindungen an alle Arbeitsprozesse. Beim Socket-Sharding wird für jeden Arbeitsprozess ein Socket-Listener erstellt, wobei der Kernel den Socket-Listenern Verbindungen zuweist, sobald diese verfügbar werden. Dadurch können Sperrkonflikte verringert und die Leistung auf Multicore-Systemen verbessert werden. Um Socket-Sharding zu aktivieren, schließen Sie den Parameter „reuseport“ in die Listen- Direktive ein.
• Thread-Pools – Jeder Computerprozess kann durch eine einzelne, langsame Operation aufgehalten werden. Bei Webserver-Software kann der Festplattenzugriff viele schnellere Vorgänge aufhalten, beispielsweise das Berechnen oder Kopieren von Informationen im Speicher. Bei Verwendung eines Thread-Pools werden langsame Vorgänge einem separaten Aufgabensatz zugewiesen, während in der Hauptverarbeitungsschleife weiterhin schnellere Vorgänge ausgeführt werden. Wenn der Festplattenvorgang abgeschlossen ist, gehen die Ergebnisse zurück in die Hauptverarbeitungsschleife. In NGINX werden zwei Operationen – der Systemaufruf read() und sendfile() – auf Thread-Pools ausgelagert.

Tipp . Wenn Sie die Einstellungen eines Betriebssystems oder unterstützenden Dienstes ändern, ändern Sie immer nur eine Einstellung auf einmal und testen Sie dann die Leistung. Wenn die Änderung Probleme verursacht oder Ihre Site dadurch nicht schneller läuft, nehmen Sie die Änderung wieder zurück.

Weitere Informationen zum Optimieren eines NGINX-Webservers finden Sie in unserem Blogbeitrag „Optimieren der Leistung von NGINX“ .

Tipp 10 – Überwachen Sie Live-Aktivitäten, 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, die Aktivität auf bestimmten Geräten und in Ihrer gesamten Web-Infrastruktur zu überwachen.

Die Überwachung der Site-Aktivität erfolgt größtenteils passiv. Sie erfahren, was los ist, und können selbst Probleme erkennen und beheben.

Durch die Überwachung können verschiedene Arten von Problemen aufgedeckt werden. Dazu gehören:

• Ein Server ist ausgefallen.
• Ein Server schwächelt und verliert Verbindungen.
• Ein Server weist eine hohe Anzahl an Cachefehlern auf.
• Ein Server sendet keinen korrekten Inhalt.

Ein globales Tool zur Überwachung der Anwendungsleistung wie New Relic oder Dynatrace hilft Ihnen, die Seitenladezeit von Remote-Standorten aus zu überwachen, während NGINX Ihnen hilft, die Anwendungsbereitstellungsseite zu überwachen. Daten zur Anwendungsleistung zeigen Ihnen, wann Ihre Optimierungen einen echten Unterschied für Ihre Benutzer bewirken und wann Sie über eine Kapazitätserweiterung Ihrer Infrastruktur nachdenken müssen, um den Datenverkehr aufrechtzuerhalten.

Um Probleme schnell zu identifizieren und zu lösen, fügt NGINX Plus anwendungsbezogene Integritätsprüfungen hinzu – synthetische Transaktionen, die regelmäßig wiederholt werden und verwendet werden, um Sie auf Probleme aufmerksam zu machen. NGINX Plus verfügt außerdem über Session Draining , das neue Verbindungen stoppt, während bestehende Aufgaben abgeschlossen werden, und eine Slow-Start-Funktion, die es einem wiederhergestellten Server ermöglicht, innerhalb einer Gruppe mit Lastenausgleich schnell hochzufahren. Bei effektiver Verwendung können Sie mit Integritätsprüfungen Probleme identifizieren, bevor diese das Benutzererlebnis erheblich beeinträchtigen. Mit Session Draining und Slow Start können Sie dagegen Server ersetzen und sicherstellen, dass der Prozess die wahrgenommene Leistung oder Betriebszeit nicht negativ beeinflusst. Die Abbildung zeigt das integrierte NGINX Plus-Dashboard zur Live-Aktivitätsüberwachung für eine Web-Infrastruktur mit Servern, TCP-Verbindungen und Caching.

Fazit – Zehnfache Leistungssteigerung

Die für einzelne Webanwendungen verfügbaren Leistungsverbesserungen können sehr unterschiedlich ausfallen. Die tatsächlichen Gewinne hängen von Ihrem Budget, der Zeit, die Sie investieren können, und den Lücken in Ihrer vorhandenen Implementierung ab. Wie können Sie also eine zehnfache Leistungssteigerung für Ihre eigenen Anwendungen erreichen?

Damit Sie die möglichen Auswirkungen der einzelnen Optimierungen besser einschätzen können, finden Sie hier Hinweise zu den Verbesserungen, die mit den oben aufgeführten Tipps möglich sind. Die Ergebnisse werden jedoch höchstwahrscheinlich unterschiedlich ausfallen:

• Reverse-Proxy-Server und Lastausgleich – Kein oder ein schlechter Lastausgleich kann zeitweise zu sehr schlechter Leistung führen. Durch das Hinzufügen eines Reverse-Proxy-Servers wie NGINX können Sie verhindern, dass Webanwendungen zwischen Speicher und Festplatte hin- und herwechseln. Durch Lastenausgleich können Verarbeitungsvorgänge von überlasteten Servern auf verfügbare Server verlagert und die Skalierung vereinfacht werden. Diese Änderungen können zu einer dramatischen Leistungssteigerung führen. Im Vergleich zu den schlimmsten Momenten Ihrer aktuellen Implementierung lässt sich problemlos eine Verbesserung um das Zehnfache erzielen. Auch bei der Gesamtleistung sind geringere, aber wesentliche Erfolge möglich.
• Zwischenspeichern von dynamischem und statischem Inhalt – Wenn Sie einen überlasteten Webserver haben, der gleichzeitig als Anwendungsserver fungiert, können Sie die Leistung in Spitzenzeiten um das Zehnfache steigern, indem Sie allein dynamische Inhalte zwischenspeichern. Auch die Zwischenspeicherung statischer Dateien kann die Leistung um ein Vielfaches steigern.
• Daten komprimieren – Die Leistung kann durch die Verwendung einer Mediendateikomprimierung wie JPEG für Fotos, PNG für Grafiken, MPEG-4 für Filme und MP3 für Musikdateien erheblich verbessert werden. Wenn alle diese Elemente verwendet werden, kann das Komprimieren von Textdaten (Code und HTML) die anfänglichen Seitenladezeiten um den Faktor zwei verbessern.
• Optimierung von SSL/TLS – Sichere Handshakes können einen großen Einfluss auf die Leistung haben, sodass ihre Optimierung möglicherweise zu einer Verdoppelung der anfänglichen Reaktionsfähigkeit führen kann, insbesondere bei textlastigen Websites. Die Optimierung der Mediendateiübertragung unter SSL/TLS bringt wahrscheinlich nur geringe Leistungsverbesserungen.
• Implementierung von HTTP/2 und SPDY – Bei Verwendung mit SSL/TLS führen diese Protokolle wahrscheinlich zu schrittweisen Verbesserungen der Gesamtleistung der Site.
• Optimieren von Linux und Webserver-Software (wie etwa NGINX) – Korrekturen wie etwa die Optimierung der Pufferung, die Verwendung von Keepalive-Verbindungen und das Auslagern zeitintensiver Aufgaben in einen separaten Thread-Pool können die Leistung deutlich steigern. Thread-Pools können beispielsweise festplattenintensive Aufgaben um fast eine Größenordnung beschleunigen.

Wir hoffen, dass Sie diese Techniken selbst ausprobieren. Wir möchten erfahren, welche Art von Leistungsverbesserungen bei Anwendungen Sie erzielen können. Teilen Sie Ihre Ergebnisse in den Kommentaren unten oder twittern Sie Ihre Geschichte mit den Hashtags #NGINX und #webperf!

Ressourcen für Internetstatistiken

Statista.com – Anteil der Internetwirtschaft am Bruttoinlandsprodukt der G‑20-Länder im Jahr 2016

Kissmetrics – Wie sich die Ladezeit auf Ihr Endergebnis auswirkt (Infografik)

Econsultancy – Site-Geschwindigkeit: Fallstudien, Tipps und Tools zur Verbesserung Ihrer Conversion-Rate