Einige Vorschläge zur Verbesserung der Nginx-Leistung

Einige Vorschläge zur Verbesserung der Nginx-Leistung

Wenn Ihre Webanwendung nur auf einer Maschine läuft, können Sie deren Leistung ganz einfach verbessern: Ersetzen Sie sie durch eine schnellere Maschine, fügen Sie mehr Prozessoren, mehr Speicher und ein Hochgeschwindigkeits-Festplatten-Array hinzu. Nach der Änderung werden der WordPress-Server sowie die Node.js- oder Java-Anwendung, die auf dieser Maschine ausgeführt werden, schneller sein. (Wenn die Anwendung auch auf einen anderen Datenbankserver zugreift, ist auch das einfach: Suchen Sie zwei schnellere Maschinen und verbinden Sie sie mit einem schnelleren Netzwerk.)
Das Problem ist, dass es nicht um die Maschinengeschwindigkeit geht. Webanwendungen sind häufig langsam, weil sie zwischen verschiedenen Aufgaben wechseln, Benutzeranforderungen über Tausende von Verbindungen verarbeiten, Dateien auf der Festplatte lesen und schreiben, Anwendungscode ausführen und andere Dinge tun müssen. Daher können auf dem Anwendungsserver verschiedene Situationen auftreten: Es kann zu Speichermangel kommen, es können Dateien ausgelagert werden oder es können viele Anfragen auf Aufgaben wie z. B. einen Festplatten-E/A warten. Zusätzlich zur Aktualisierung der Hardware können Sie tatsächlich einen völlig anderen Ansatz wählen: Fügen Sie einen Reverse-Proxy-Server hinzu, um einige der oben genannten Aufgaben zu teilen. Der Reverse-Proxy-Server befindet sich vor dem Computer, auf dem die Anwendung ausgeführt wird, und ist für die Verarbeitung von Anfragen aus dem externen Netzwerk verantwortlich. Der Reverse-Proxy-Server ist direkt mit dem Internet verbunden und kommuniziert mit dem Anwendungsserver über ein schnelles internes Netzwerk. Der Reverse-Proxy-Server ermöglicht es dem Anwendungsserver, sich auf das Erstellen von Seiten zu konzentrieren, die dann an den Reverse-Proxy ins externe Netzwerk gesendet werden, ohne sich um die Interaktion zwischen Benutzern und der Anwendung kümmern zu müssen. Da der Anwendungsserver nicht auf eine Antwort vom Client warten muss, kann er mit nahezu optimaler Geschwindigkeit laufen.
Durch das Hinzufügen eines Reverse-Proxy-Servers können Sie auch die Flexibilität Ihres Webservers erhöhen. Wenn beispielsweise ein Server, der eine bestimmte Aufgabe ausführt, überlastet ist, können Sie jederzeit einen anderen Server desselben Typs hinzufügen. Und wenn dieser Server abstürzt, lässt er sich auch problemlos ersetzen. Aufgrund dieser Flexibilität ist ein Reverse-Proxy-Server häufig Voraussetzung für andere Techniken zur Leistungsoptimierung, beispielsweise:

  • Lastenausgleich (siehe „Vorschlag 2“): Führen Sie auf dem Reverse-Proxy-Server einen Lastenausgleichsdienst aus, um den Datenverkehr gleichmäßig auf mehrere Anwendungsserver zu verteilen. Durch den Lastenausgleich ist zum Hinzufügen von Anwendungsservern keinerlei Änderung der Anwendung erforderlich.
  • Statische Dateien zwischenspeichern (siehe „Empfehlung 3“), direkt abrufbare Dateien wie Bilder oder Codes können im Reverse-Proxy-Server gespeichert werden, um diese direkt an den Client zu senden. Dadurch werden nicht nur Anfragen schneller beantwortet, sondern auch die Anwendungsserver werden entlastet und laufen schneller.
  • Um die Site-Sicherheit zu gewährleisten, können Sie einen Reverse-Proxy-Server konfigurieren, um dessen Sicherheitsstufe zu verbessern und ihn zum Überwachen und schnellen Identifizieren und Reagieren auf Angriffe zu verwenden, wodurch die Sicherheit des Anwendungsservers gewahrt bleibt.

NGINX ist speziell für die Verwendung als Reverse-Proxy-Server konzipiert und unterstützt daher automatisch die oben genannten Optimierungen. Da NGINX ereignisgesteuerte Verarbeitung verwendet, ist es effizienter als herkömmliche Server. NGINX Plus fügt erweiterte Reverse-Proxy-Funktionen hinzu, wie z. B. Anwendungsintegritätsprüfungen, einzigartiges Anforderungsrouting, erweitertes Caching und After-Sales-Support.

Vorschlag 2: Fügen Sie einen Lastenausgleichsserver hinzu

Das Hinzufügen eines Lastausgleichsservers ist relativ einfach, kann aber die Leistung und Sicherheit einer Site erheblich verbessern. Durch die Verteilung des Datenverkehrs auf mehrere Server müssen Sie Ihren Webserver nicht aktualisieren. Auch wenn die Anwendung selbst nicht gut geschrieben oder schwer skalierbar ist, kann durch Lastenausgleich das Benutzererlebnis ohne weitere Änderungen verbessert werden.
Bei dem Loadbalancing-Server handelt es sich zunächst um einen Reverse-Proxy-Server (siehe „Vorschlag 1“), der für die Weiterleitung von Anfragen aus dem Internet an andere Server zuständig ist. Der Schlüssel liegt hierbei darin, dass der Lastausgleichsserver mehr als zwei Anwendungsserver unterstützen und einen Auswahlalgorithmus verwenden kann, um Anforderungen auf verschiedene Server zu verteilen. Der einfachste Lastausgleichsalgorithmus ist die Round-Robin-Planung, bei der neue Anforderungen nacheinander an den nächsten verfügbaren Server weitergeleitet werden. Andere Algorithmen senden Anfragen an den Server mit den wenigsten aktiven Verbindungen. NGINX Plus unterstützt eine Funktion namens Sitzungspersistenz, die Benutzersitzungen auf demselben Server hält. Durch Lastenausgleichsserver kann die Überlastung eines Servers während der Leerlaufzeit anderer Server verhindert und so die Leistung erheblich verbessert werden. Gleichzeitig kann dadurch auch die Kapazitätserweiterung des Webservers erleichtert werden, da günstigere Server gewählt werden können und gleichzeitig eine volle Auslastung gewährleistet ist. Zu den Protokollen, die durch Lastausgleich geplant werden können, gehören HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI, SCGI, uwsgi, memcached und einige andere Anwendungsformen, darunter TCP-basierte Anwendungen und andere Protokolle der vierten Schicht. Dazu müssen Sie zunächst die Webanwendung analysieren, um die Leistungsdefizite zu ermitteln und dann entscheiden, welche Sie verwenden möchten. Derselbe oder dieselben Server, die zum Lastenausgleich verwendet werden, können auch andere Aufgaben übernehmen, wie etwa die SSL-Terminierung, die Unterstützung von HTTP/1/x oder HTTP/2 (je nach Client) und das Zwischenspeichern statischer Dateien. NGINX wird häufig zum Lastenausgleich verwendet. Weitere Informationen finden Sie in unseren vorherigen Einführungsartikeln, Konfigurationsartikeln, E-Books, zugehörigen Online-Videos und natürlich in der Dokumentation. Unsere kommerzielle Version, NGINX Plus, unterstützt mehr Lastausgleichsfunktionen, wie z. B. die Weiterleitung von Lasten basierend auf der Serverantwortzeit und einen Lastausgleich, der das Microsoft NTLM-Protokoll unterstützt.

Tipp 3: Statische und dynamische Inhalte zwischenspeichern

Durch die Zwischenspeicherung können Sie die Leistung von Webanwendungen verbessern, indem Sie Inhalte schneller an Clients übermitteln. Zu den Caching-Strategien gehören die Vorverarbeitung von Inhalten, die Speicherung von Inhalten auf schnelleren Geräten, die Aufbewahrung von Inhalten in der Nähe des Clients und eine Kombination dieser Strategien. Es gibt zwei Cache-Typen.

  • Zwischenspeichern statischer Inhalte: Sich selten ändernde Dateien wie Bilder (JPEG, PNG) und Code (CSS, JavaScript) können auf Edge-Servern gespeichert werden, um sie schnell vom Inhalt oder von der Festplatte abzurufen.
  • Dynamisches Zwischenspeichern von Inhalten. Viele Webanwendungen generieren bei jeder Seitenanforderung neues HTML. Durch das Zwischenspeichern jedes generierten HTML für einen kurzen Zeitraum kann die Gesamtzahl der zu generierenden Seiten erheblich reduziert werden, während gleichzeitig sichergestellt wird, dass der bereitgestellte Inhalt aktuell genug ist.

Angenommen, eine Seite wird 10 Mal pro Sekunde aufgerufen und Sie speichern sie 1 Sekunde lang im Cache. Dann stammen 90 % der Anforderungen für diese Seite aus dem Cache. Wenn Sie statische Inhalte separat zwischenspeichern, wird selbst eine neu generierte Seite wahrscheinlich größtenteils aus zwischengespeicherten Inhalten bereitgestellt. Es gibt drei Haupttechniken zum Zwischenspeichern von von Webanwendungen generierten Inhalten.

  • Platzieren Sie die Inhalte in der Nähe der Benutzer. Nah am Benutzer, kürzere Übertragungszeit.
  • Stellen Sie den Inhalt auf einen schnelleren Rechner. Die Maschine ist schnell und die Abrufgeschwindigkeit ist hoch.
  • Entfernen Sie Inhalte von überbeanspruchten Maschinen. Manchmal sind Maschinen viel langsamer, als wenn sie sich auf eine bestimmte Aufgabe konzentrieren würden, weil sie durch zu viele Aufgaben abgelenkt werden. Derzeit ist das Verschieben des Inhalts auf andere Maschinen nicht nur für zwischengespeicherte Inhalte vorteilhaft, sondern auch für nicht zwischengespeicherte Inhalte, da die Belastung des Hosts, auf dem sie gehostet werden, reduziert wird.

Das Caching von Webanwendungen kann innerhalb oder außerhalb des Webanwendungsservers implementiert werden. Erwägen Sie zunächst das Zwischenspeichern dynamischer Inhalte, um die Belastung Ihrer Anwendungsserver zu verringern. Zweitens wird für statische Inhalte (einschließlich temporärer Kopien dynamisch generierter Inhalte) Caching verwendet, was die Belastung der Anwendungsserver weiter reduziert. Erwägen Sie dann, den Cache auf andere Maschinen zu verschieben, die schneller sind oder sich näher am Benutzer befinden, um die Belastung des Anwendungsservers zu verringern und die Übertragungszeit zu verkürzen. Die ordnungsgemäße Verwendung des Cache kann die Reaktion Ihrer Anwendung erheblich beschleunigen. Bei vielen Webseiten nehmen statische Daten wie große Bilder oft mehr als die Hälfte des Inhalts ein. Ohne Caching könnte das Abfragen und Übertragen dieser Datenart mehrere Sekunden dauern, mit Caching dauert es jedoch möglicherweise nur den Bruchteil einer Sekunde. Um die Verwendung des Cachings zu veranschaulichen, richten NGINX und NGINX Plus das Caching mit zwei Anweisungen ein: proxy_cache_path und proxy_cache, die den Speicherort und die Größe des Caches, die maximale Cache-Zeit und andere Parameter angeben. Mit der dritten (und beliebten) Direktive proxy_cache_use_stale können Sie dem Cache sogar sagen, alte Dateien bereitzustellen, wenn der Server, der neue Inhalte bereitstellen sollte, überlastet oder ausgefallen ist. Für den Client ist es immer besser, die Inhalte zu erhalten, als sie gar nicht zu erhalten. Aus Sicht des Benutzers kann dies auch den Eindruck vermitteln, dass Ihre Site oder Anwendung sehr stabil ist. NGINX Plus unterstützt erweiterte Caching-Funktionen, einschließlich Cache-Bereinigung und einem Dashboard, das den Cache-Status zur Echtzeitüberwachung visualisiert. Weitere Informationen zum Caching in NGINX finden Sie unter „NGINX Content Caching“ in der Referenzdokumentation und im NGINX Plus Admin Guide. Hinweis: Caching umfasst Entwicklung, Entscheidungsfindung und Betrieb. Eine umfassende Caching-Strategie wie die in diesem Artikel beschriebene kann sich aus der DevOps-Perspektive als wertvoll erweisen. Mit anderen Worten: Entwickler, Architekten sowie Betriebs- und Wartungspersonal arbeiten zusammen, um die Funktionalität, Reaktionszeit, Sicherheit und Geschäftsziele einer Website sicherzustellen.

Tipp 4: Daten komprimieren

Durch Komprimierung kann die Leistung ebenfalls erheblich verbessert werden. Es gibt sehr ausgereifte und effiziente Komprimierungsstandards für Bilder, Videos, Musik und andere Dateien (JPEG und PNG, MPEG-4, MP3), von denen jeder die Dateigröße um eine Größenordnung oder mehr reduzieren kann.
Textdateien, einschließlich HTML- (Klartext und HTML-Tags), CSS- und JavaScript-Code, werden häufig ohne Komprimierung übertragen. Durch das Komprimieren dieser Daten kann die wahrgenommene Leistung einer Webanwendung manchmal erheblich verbessert werden, insbesondere für mobile Benutzer mit langsamen und unzuverlässigen Verbindungen. Denn Textdaten können bei der Seiteninteraktion eine notwendige unterstützende Rolle spielen, während Multimediadaten eher das Tüpfelchen auf dem i sind. Durch intelligente Inhaltskomprimierung kann die Größe von Textinhalten wie HTML, JavaScript, CSS usw. um mehr als 30 % reduziert und so die Ladezeit entsprechend verkürzt werden.
Wenn Sie SSL verwenden, kann durch Komprimierung die Datenmenge reduziert werden, die SSL-codiert werden muss, und so die für die Komprimierung dieser Daten aufgewendete CPU-Zeit ausgeglichen werden.
Es gibt viele Möglichkeiten, Daten zu komprimieren. Beispielsweise wird im Abschnitt zu HTTP/2 in Empfehlung 6 eine neuartige Komprimierungsidee beschrieben, die sich insbesondere für die Komprimierung von Header-Daten eignet. Als weiteres Beispiel für Textkomprimierung können Sie die GZIP-Komprimierung in NGINX aktivieren. Nach dem Vorkomprimieren der Textdaten können Sie die GZ-Datei mit der Direktive gzip_static direkt senden.

Tipp 5: SSL/TLS optimieren

Immer mehr Websites verwenden die Protokolle Secure Sockets Layer (SSL) und später Transport Layer Security (TLS). SSL/TLS verbessert die Website-Sicherheit durch Verschlüsselung der vom Ursprungsserver an den Benutzer gesendeten Daten. Google wird diesen Prozess deutlich vorantreiben, indem es das Suchmaschinen-Ranking von Websites verbessert, die SSL/TLS verwenden.
Trotz zunehmender Verbreitung leiden viele Websites unter den durch SSL/TLS verursachten Leistungseinbußen. Es gibt zwei Gründe, warum SSL/TLS Ihre Website verlangsamt. 1. Beim ersten Handshake, der jede neue Verbindung öffnet, müssen Verschlüsselungsschlüssel erstellt werden. Die Art und Weise, wie Browser HTTP/1.x verwenden, um mehrere Verbindungen zu jedem 2. Server herzustellen, verschärft dieses Problem noch weiter. Auch die Vorgänge zum Verschlüsseln der Daten auf der Serverseite und zum Entschlüsseln der Daten auf der Clientseite verursachen Mehraufwand. Um die Nutzung von SSL/TLS zu fördern, haben die Autoren von HTTP/2 und SPDY (siehe Empfehlung 6) diese beiden Protokolle so konzipiert, dass Browser nur eine Verbindung pro Sitzung herstellen können. Dadurch wird einer der beiden Hauptgründe beseitigt, warum SSL die Leistung beeinträchtigen kann. Allerdings kann bei der Optimierung der SSL/TLS-Leistung noch viel getan werden. Die Methoden zur Optimierung von SSL/TLS variieren von Webserver zu Webserver. Nehmen wir NGINX als Beispiel. NGINX verwendet OpenSSL und läuft auf normalen Maschinen, wodurch eine Leistung erreicht wird, die der von angepassten Maschinen nahe kommt. Die Leistung von NGINX SSL erläutert, wie der Aufwand für die SSL/TLS-Verschlüsselung und -Entschlüsselung minimiert werden kann. Darüber hinaus finden Sie hier einen Artikel, der viele Möglichkeiten zur Verbesserung der SSL/TLS-Leistung vorstellt. Um es kurz zusammenzufassen: Die wichtigsten beteiligten Technologien sind die folgenden.

  • Sitzungscache. Verwenden Sie die Direktive ssl_session_cache, um das Caching zu aktivieren und die für jede SSL/STL-Verbindung verwendeten Parameter zwischenzuspeichern.
  • Sitzungsticket oder Ausweis. Speichert Informationen zu einer bestimmten SSL/TLS-Sitzung als Sitzungsticket oder ID, sodass die Verbindung ohne erneuten Handshake wiederverwendet werden kann.
  • OCSP-Umschlag. Reduzieren Sie die Handshake-Zeit, indem Sie SSL/TLS-Zertifikatsinformationen zwischenspeichern.

Sowohl NGINX als auch NGINX Plus können SSL/TLS beenden, was bedeutet, dass sie die Ver- und Entschlüsselung clientseitiger Informationen handhaben und gleichzeitig die Klartextkommunikation mit anderen Servern aufrechterhalten. Das Einrichten von NGINX oder NGINX Plus zur Handhabung der SSL/TLS-Terminierung kann mehrere Schritte umfassen. Um NGINX Plus auf einem Server zu verwenden, der TCP-Verbindungen akzeptiert, befolgen Sie die Einrichtungsanweisungen hier.

Empfehlung 6: Implementieren Sie HTTP/2 oder SPDY

Websites, die bereits SSL/TLS verwenden, werden wahrscheinlich Leistungsverbesserungen feststellen, wenn sie HTTP/2 oder SPDY verwenden, da für eine Verbindung nur ein Handshake erforderlich ist. Bei Websites, die nicht bereits SSL/TLS, HTTP/2 und SPDY verwenden, kann es zu einer Verschlechterung der Reaktionsfähigkeit kommen, wenn sie auf SSL/TLS umsteigen (was normalerweise zu Leistungseinbußen führt).
Google startete das SPDY-Projekt im Jahr 2012 mit dem Ziel, höhere Geschwindigkeiten auf Basis von HTTP/1.x zu erreichen. HTTP/2 ist ein kürzlich von der IETF genehmigter Standard, der auf SPDY basiert. SPDY wird weitgehend unterstützt, wird aber bald durch HTTP/2 ersetzt.
Der Schlüssel zu SPDY und HTTP/2 besteht darin, nur eine Verbindung anstelle mehrerer Verbindungen zu verwenden. Diese einzelne Verbindung ist multiplexiert, sodass sie mehrere Anfragen und Antworten gleichzeitig übertragen kann.
Durch die Aufrechterhaltung nur einer Verbindung entfällt der Einrichtungs- und Verwaltungsaufwand mehrerer Verbindungen. Und eine Verbindung ist für SSL besonders wichtig, da dadurch die für den Aufbau einer sicheren Verbindung für SSL/TLS erforderliche Handshake-Zeit minimiert werden kann.
Das SPDY-Protokoll erfordert die Verwendung von SSL/TLS, was für HTTP/2 nicht offiziell erforderlich ist, aber alle Browser, die derzeit HTTP/2 unterstützen, verwenden es nur, wenn SSL/TLS aktiviert ist. Mit anderen Worten: Ein Browser, der HTTP/2 unterstützt, verwendet HTTP/2 nur, wenn die Website SSL verwendet und der Server HTTP/2-Verkehr akzeptiert. Andernfalls kommuniziert der Browser auf Basis von HTTP/1.x.
Nach der Implementierung von SPDY oder HTTP/2 sind vorherige Maßnahmen zur Leistungsoptimierung für HTTP, wie etwa Domain Name Sharding, Ressourcenzusammenführung und Bild-Sprites, nicht mehr erforderlich. Daher können auch der Code und die Bereitstellung vereinfacht werden. Weitere Informationen zu den Änderungen, die HTTP/2 mit sich bringt, finden Sie in unserem Whitepaper.

NGINX unterstützt SPDY schon seit langem und die meisten Websites, die heute SPDY verwenden, laufen unter NGIN
X. NGINX war auch das erste Unternehmen, das HTTP/2 unterstützte. Im September 2015 begannen NGINX Open Source und NGINX Plus, HTTP/2 zu unterstützen.
NGINX geht davon aus, dass die meisten Websites mit der Zeit SSL aktivieren und zu HTTP/2 migrieren. Dadurch wird die Website nicht nur sicherer, sondern es ist auch eine höhere Leistung mit einfacherem Code möglich, wenn neue Optimierungstechniken auftauchen.

Empfehlung 7: Software-Upgrade

Eine einfache Möglichkeit, die Anwendungsleistung zu verbessern, besteht darin, Software auf der Grundlage von Zuverlässigkeit und Leistung auszuwählen. Darüber hinaus ist es wahrscheinlicher, dass Entwickler qualitativ hochwertiger Komponenten die Leistung kontinuierlich verbessern und Probleme beheben, sodass es kosteneffizient ist, die neueste stabile Version zu verwenden. Neue Versionen erhalten mehr Aufmerksamkeit von Entwicklern und Benutzern und profitieren außerdem von neuen Compiler-Optimierungstechniken, einschließlich der Abstimmung auf neue Hardware. Im Vergleich zur alten Version weist die neu veröffentlichte stabile Version deutlich eine höhere Leistung auf. Indem Sie die Upgrades im Auge behalten, bleiben Sie auch hinsichtlich Optimierungen, Problembehebungen und Sicherheitswarnungen auf dem neuesten Stand. Auch das Versäumnis, Software zu aktualisieren, kann die Nutzung neuer Funktionen behindern. Beispielsweise erfordert HTTP/2 derzeit OpenSSL 1.0.1. Ab der zweiten Hälfte des Jahres 2016 erfordert HTTP/2 OpenSSL 1.0.2, das im Januar 2015 veröffentlicht wurde. NGINX-Benutzer können mit der neuesten Version der NGINX Open Source-Software oder NGINX Plus beginnen, das Socket-Sharing, Thread-Pools (siehe unten) und kontinuierliche Leistungsoptimierungen unterstützt. Überprüfen Sie also Ihre Software und versuchen Sie, sie auf die neueste Version zu aktualisieren.

Tipp 8: Linux optimieren

Linux ist heute das zugrunde liegende Betriebssystem für die meisten Webserver. Als Grundlage der gesamten Infrastruktur ist Linux für die Leistungssteigerung von entscheidender Bedeutung. Viele Linux-Systeme sind standardmäßig relativ konservativ, wobei die Anforderungen an die Desktop-Office-Umgebung die einzige Anforderung und das Optimierungsziel eine geringe Menge an Ressourcen sind. Bei Webanwendungen ist eine Neuoptimierung unbedingt erforderlich, um eine optimale Leistung zu erzielen. Die Linux-Optimierung variiert von Webserver zu Webserver. Am Beispiel von NGINX können wir die folgenden Aspekte berücksichtigen.
Inventarwarteschlange. Wenn Sie feststellen, dass einige Verbindungen nicht verarbeitet werden, können Sie net.core.somaxconn erhöhen. Dies ist die maximale Anzahl von Verbindungen, die darauf warten, von NGINX verarbeitet zu werden. Wenn das Verbindungslimit zu niedrig ist, sollten Sie Fehlermeldungen sehen und können diesen Wert schrittweise erhöhen, bis die Fehlermeldungen nicht mehr erscheinen.

  • Dateideskriptor. NGINX verwendet höchstens zwei Dateideskriptoren pro Verbindung. Wenn das System viele Verbindungen bedient, müssen Sie möglicherweise das systemweite Limit für Deskriptoren (sys.fs.file_max) und das Benutzerlimit für Dateideskriptoren (nofile) erhöhen, um die erhöhte Last zu unterstützen.
  • Vergänglicher Hafen. Bei Verwendung als Proxy erstellt NGINX temporäre Ports für jeden Upstream-Server. Sie können net.ipv4.ip_local_port_range festlegen, um den Bereich der Portwerte zu vergrößern und so die Menge der verfügbaren Ports zu erhöhen. Darüber hinaus können Sie auch den Wert von net.ipv4.tcp_fin_timeout reduzieren, der die Wartezeit steuert, bevor inaktive Ports zur Wiederverwendung freigegeben werden, um den Umsatz zu beschleunigen.
  • Informationen zu NGINX finden Sie im NGINX Performance Tuning Guide, um zu erfahren, wie Sie Ihr Linux-System mühelos optimieren können, um einen höheren Durchsatz zu erreichen.

Tipp 9: Optimieren Sie Ihren Webserver

Egal welchen Webserver Sie verwenden, Sie müssen ihn für Ihre Anwendung optimieren. Die folgenden Vorschläge gelten für alle Webserver, Einrichtungsanweisungen werden jedoch nur für NGINX gegeben.

  • Zugriffsprotokolle. Schreiben Sie nicht jedes Anforderungsprotokoll sofort auf die Festplatte. Sie können sie im Speicher zwischenspeichern und dann stapelweise verarbeiten. Fügen Sie für NGINX den Parameter buffer=_size_ zur access_log-Direktive hinzu, um zu warten, bis der Speicherpuffer voll ist, bevor das Protokoll auf die Festplatte geschrieben wird. Wenn Sie den Parameter **flush=_time_** hinzufügen, wird der Pufferinhalt zum angegebenen Zeitpunkt ebenfalls auf die Festplatte geschrieben.
  • Puffer. Durch Pufferung werden Teilantworten im Speicher gespeichert, bis der Puffer gefüllt ist. Dies ermöglicht effizientere Antworten an Clients. Antworten, die nicht in den Speicher passen, werden auf die Festplatte geschrieben, was die Leistung beeinträchtigt. Wenn die NGINX-Pufferung aktiviert ist, kann sie mit den Anweisungen proxy_buffer_size und proxy_buffers verwaltet werden.
  • Aktive Clientverbindungen. Aktive Verbindungen können die Latenz reduzieren, insbesondere bei Verwendung von SSL/TLS. Für NGINX können Sie den Wert von „keepalive_requests“ für den Client erhöhen, der standardmäßig auf 100 eingestellt ist. Sie können auch den Wert von „keepalive_timeout“ erhöhen, damit aktive Verbindungen länger bestehen bleiben, sodass auf nachfolgende Anfragen schneller geantwortet werden kann.
  • Upstream-Aktivverbindung. Auch Upstream-Verbindungen, also Verbindungen zu Anwendungsservern und Datenbankservern, können vom Setzen aktiver Verbindungen profitieren. Bei Upstream-Verbindungen können Sie die Anzahl der aktiven Verbindungen erhöhen, also die Anzahl der inaktiven aktiven Verbindungen, die jedem Arbeitsprozess zur Verfügung stehen. Dadurch kann die Wiederverwendung von Verbindungen verbessert und die Anzahl erneuter Verbindungsöffnungen verringert werden. Weitere Informationen zu aktiven Verbindungen finden Sie in diesem Blogbeitrag.
  • Limit. Durch die Begrenzung der von Clients verwendeten Ressourcen können Leistung und Sicherheit verbessert werden. Bei NGINX begrenzen die Anweisungen limit_conn und limit_conn_zone die Anzahl der Verbindungen von einer angegebenen Quelle, während limit_rate die Bandbreite begrenzt. Diese Einstellungen verhindern, dass legitime Benutzer Ressourcen „stehlen“, und tragen außerdem dazu bei, Angriffe zu verhindern. Die Anweisungen limit_req und limit_req_zone begrenzen Clientanforderungen. Für Verbindungen zu Upstream-Servern können Sie im Upstream-Konfigurationsbereich den Parameter max_conns in der Server-Direktive verwenden, der die Anzahl der Verbindungen zum Upstream-Server begrenzt, um eine Überlastung zu vermeiden. Die zugehörige Warteschlangendirektive erstellt eine Warteschlange, die die angegebene Anzahl von Anforderungen für die angegebene Zeit enthält, nachdem das max_conns-Limit erreicht wurde.
  • Arbeitsprozess. Arbeitsprozesse sind für die Bearbeitung von Anfragen zuständig. NGINX verwendet ein ereignisbasiertes Modell und betriebssystemabhängige Mechanismen, um Anfragen effizient auf die Arbeitsprozesse zu verteilen. Es wird empfohlen, den Wert von worker_processes auf einen Workerprozess pro CPU festzulegen. Die meisten Systeme unterstützen bei Bedarf die Erhöhung des Werts von worker_connections (der Standardwert ist 512). Experimentieren Sie, um den Wert zu finden, der für Ihr System am besten funktioniert.
  • Socket-Sharding. Normalerweise verteilt ein Socket-Listener neue Verbindungen an alle Arbeitsprozesse. Beim Socket-Sharding wird für jeden Arbeitsprozess ein Socket-Listener erstellt und der Kernel weist dem Socket-Listener eine Verbindung zu, wenn dieser verfügbar ist. Dadurch können Sperrkonflikte verringert und die Leistung auf Mehrkernsystemen verbessert werden. Um Socket-Sharding zu aktivieren, schließen Sie den Parameter „reuseport“ in die Listen-Direktive ein.
  • Threadpool. Ein zeitaufwändiger Vorgang kann jeden Computerprozess blockieren. Bei Webserver-Software kann der Festplattenzugriff viele schnellere Vorgänge behindern, beispielsweise Berechnungen und Replikationen im Arbeitsspeicher. 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. Sobald der Festplattenvorgang abgeschlossen ist, werden die Ergebnisse an die Hauptverarbeitungsschleife zurückgegeben. In NGINX werden der Systemaufruf read() und sendfile() in den Thread-Pool ausgelagert.

Tipp: Wenn Sie die Einstellungen eines Betriebssystems oder Peripheriegeräts ändern, ändern Sie immer nur ein Element auf einmal und testen Sie dann die Leistung. Wenn die Änderung Probleme verursacht oder die Leistung nicht verbessert, nehmen Sie die Änderung wieder vor.

Tipp 10: Überwachen Sie die Dynamik in Echtzeit, um Probleme und Engpässe zu identifizieren

Der Schlüssel zur Aufrechterhaltung einer hohen Anwendungsleistung liegt in der Überwachung der Anwendungsleistung in Echtzeit. Die Dynamik von Anwendungen auf bestimmten Geräten und der entsprechenden Web-Infrastruktur muss in Echtzeit überwacht werden.
Die Überwachung der Site-Aktivität erfolgt größtenteils passiv. Sie erfahren, was passiert, aber es liegt an Ihnen, Probleme zu finden und zu beheben.
Durch die Überwachung können folgende Probleme erfasst werden: 1. Serverausfall 2. Serverinstabilität, verpasste Verbindung 3. Umfangreicher Cache-Fehler auf dem Server 4. Vom Server gesendeter falscher Inhalt
Mithilfe globaler Leistungsüberwachungstools wie New Relic oder Dynatrace können wir die zum Laden von Remoteseiten benötigte Zeit überwachen, während NGINX Ihnen bei der Überwachung der Anwendungsbereitstellung helfen kann. Anhand der Leistungsdaten Ihrer App können Sie erkennen, wann Ihre Optimierungen für Ihre Benutzer wirklich von Vorteil sind und wann Sie die Leistung erhöhen müssen, um dem steigenden Datenverkehr gerecht zu werden.
Damit Benutzer Probleme so schnell wie möglich erkennen können, wurde in NGINX Plus eine Funktion zur Überprüfung der Anwendungsintegrität hinzugefügt, die häufig auftretende Probleme meldet. NGINX Plus verfügt außerdem über eine Session-Draining-Funktion, die neue Verbindungen blockiert, bis bestehende Aufgaben abgeschlossen sind, sowie über eine Slow-Start-Kapazität, um wiederhergestellten Servern das Hochfahren in einem Cluster mit Lastenausgleich zu ermöglichen. Bei ordnungsgemäßer Verwendung können Sie mit Integritätsprüfungen Probleme erkennen, bevor diese die Benutzererfahrung erheblich beeinträchtigen. Mit Session Draining und Slow Start können Sie Server ersetzen, ohne die wahrgenommene Leistung und Betriebszeit zu beeinträchtigen. Dieses Bild zeigt das Dashboard für die integrierte Echtzeit-Aktivitätsüberwachung von NGINX Plus, die Server, TCP-Verbindungen und Cache abdeckt.

Fazit: 10-fache Leistungssteigerung

Die Leistungsverbesserung kann von einer Webanwendung zur anderen erheblich unterschiedlich ausfallen. Die tatsächliche Verbesserung hängt vom Budget, der Zeit und der Lücke zwischen der vorhandenen Implementierung und der idealen Leistung ab. Wie können Sie also die Leistung Ihrer Anwendung um das Zehnfache steigern? Damit Sie das Potenzial jedes Optimierungsvorschlags besser verstehen, stellen wir Ihnen einige Implementierungsrichtlinien für die vorherigen Vorschläge zur Verfügung. Ich hoffe, jeder kann sich das nehmen, was er braucht.

  • Reverse-Proxy-Server und Lastenausgleich. Kein Lastausgleich oder gepoolter Lastausgleich kann zu sehr schlechter Leistung führen. Durch das Hinzufügen eines Reverse-Proxy-Servers wie NGINX können Sie die Anzahl der Roundtrips Ihrer Webanwendung zwischen Speicher und Festplatte reduzieren. Durch Lastausgleich können Aufgaben von überlasteten Servern auf inaktive Server übertragen werden. Zudem wird eine Erweiterung erleichtert. Diese Änderungen können die Leistung erheblich verbessern. Verglichen mit dem Worst-Case der ursprünglichen Bereitstellungsmethode ist eine Leistungssteigerung um das Zehnfache eine sehr einfache Sache. Selbst wenn es weniger als das Zehnfache ist, ist es insgesamt ein qualitativer Sprung.
  • Zwischenspeichern Sie dynamische und statische Inhalte. Wenn Ihr Webserver auch als Anwendungsserver fungiert, können Sie durch das Zwischenspeichern dynamischer Inhalte eine zehnfache Leistungssteigerung in Spitzenzeiten erzielen. Das Zwischenspeichern statischer Inhalte kann die Leistung ebenfalls um ein Vielfaches verbessern.
  • Daten komprimieren. Die Verwendung von Komprimierungsformaten wie JPEG, PNG, MPEG-4 und MP3 kann die Leistung erheblich verbessern. Wenn alle diese Maßnahmen verwendet werden, können komprimierte Textdaten (Code und HTML) die anfängliche Seitenladezeit um das Zweifache verkürzen.
  • Optimieren Sie SSL/TLS. Der Sicherheits-Handshake wirkt sich erheblich auf die Leistung aus. Durch seine Optimierung können die ersten Antworten bis zu doppelt so schnell erfolgen, insbesondere bei Websites mit viel Text. Die Optimierung von Mediendateien für SSL/TLS bringt nur eine geringe Leistungsverbesserung.
  • Implementieren Sie HTTP/2 und SPDY. Bei Verwendung von SSL/TLS können diese beiden Protokolle die Gesamtleistung Ihrer Website verbessern.
  • Tuning von Linux und Webservern. Durch die Verwendung optimierter Pufferstrategien, die Nutzung aktiver Verbindungen und die Auslagerung zeitaufwändiger Aufgaben auf unabhängige Thread-Pools kann die Leistung erheblich verbessert werden. Beispielsweise können Thread-Pools die Leistung datenträgerintensiver Aufgaben um mindestens eine Größenordnung verbessern.

Oben finden Sie einige Vorschläge zur Verbesserung der Nginx-Leistung. Weitere Informationen zur Verbesserung der Nginx-Leistung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • Beispiel für das Upgrade von nginx zur Unterstützung von HTTP2.0
  • So führen Sie in 1 Minute ein reibungsloses Upgrade und Rollback der Nginx-Version durch
  • Detaillierte Erläuterung der Lösung zum reibungslosen Upgrade der Nginx-Version
  • So aktualisieren Sie Nginx zur Unterstützung von http2
  • Installation des Nginx-Dienstes und Software-Upgrade

<<:  Zusammenfassung der MySQL-Datenbank-ähnlichen Anweisung zur Platzhalter-Fuzzy-Abfrage

>>:  Eine kurze Diskussion über Makrotasks und Mikrotasks in js

Artikel empfehlen

Centos erstellt ein Prozessdiagramm für den Chrony-Zeitsynchronisationsserver

Meine Umgebung: 3 centos7.5 1804 Meister 192.168....

So spielen Sie lokale Mediendateien (Video und Audio) mit HTML und JavaScript ab

Erstens kann JavaScript aus Sicherheitsgründen ni...

Anweisungen zur Verwendung von JSON-Operationsfunktionen in Mysql5.7

Vorwort JSON ist ein leichtes Datenaustauschforma...

Nutzungs- und Best-Practice-Handbuch für die Überwachung in Vue3

Inhaltsverzeichnis Vorwort 1. API-Einführung 2. Ü...

W3C Tutorial (1): W3C verstehen

Das W3C, eine 1994 gegründete Organisation, zielt...

JavaScript-Code zum Erzielen eines einfachen Kalendereffekts

In diesem Artikel wird der spezifische Code für J...

So betten Sie Dateien im Flash-Videoformat (FLV, SWF) in HTML-Dateien ein

Flash-Dateiformate: .FLV und .SWF Für das Flash-Vi...

Verwendung und Optimierung der MySQL COUNT-Funktion

Inhaltsverzeichnis Was macht die Funktion COUNT? ...