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.
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:
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.
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.
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:
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:
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.
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.
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:
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:
„ssl_session_cache“
, um die Parameter zwischenzuspeichern, die beim Sichern jeder neuen Verbindung mit SSL/TLS verwendet werden.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 .
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.
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.
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:
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.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.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.
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:
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.proxy_buffer_size
und proxy_buffers,
um sie zu verwalten.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.„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“ .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.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.„reuseport“
in die Listen-
Direktive ein.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“ .
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 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.
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:
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!
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)
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."