Was sind die optimalen Einstellungen für die Verwendung von Apache oder NGINX als Backend-Server für ELB?

Lesedauer: 3 Minute
0

Ich möchte eine Amazon Elastic Compute Cloud (Amazon EC2)-Instanz mit Apache oder NGINX als Backend-Server für Elastic Load Balancing (ELB) verwenden. Ich weiß jedoch nicht, welche Einstellungen ich für die beste Leistung verwenden soll.

Behebung

Die besten Einstellungen für einen Lastenausgleicher hängen von Ihrem Anwendungsfall ab. Um die beste Leistung zu erzielen, analysieren Sie die Reaktionszeiten Ihrer Backend-Anwendung und die Anforderungen Ihrer Kunden.

Wenn die Backend-Anwendung Apache oder NGINX ausführt, überprüfen Sie die folgenden Parameter:

Client-Header-Timeout(Timeoutin Apache;Client_header_timeoutin NGINX):
Stellen Sie den Timeout-Wert Ihrer Anwendung auf einen höheren Wert als den Leerlauf-Timeout-Wert des Lastenausgleichers. So stellen Sie sicher, dass der Lastenausgleicher inaktive Verbindungen ordnungsgemäß schließt. Wenn der Backend-Server eine Verbindung ohne ordnungsgemäße Benachrichtigung des Lastenausgleichers abbricht, erhalten Sie möglicherweise einen 504-Fehler.

Keep-Alive(KeepAlivein Apache;keepalive_disablein NGINX):
Aktivieren Sie Keep-Alive, um die CPU-Auslastung zu reduzieren und die Reaktionszeit zu verbessern. Bei aktivierter Keep-Alive-Funktion muss der Lastenausgleicher nicht für jede HTTP-Anfrage eine neue TCP-Verbindung aufbauen.

Keep-Alive-Timeout(KeepAliveTimeoutin Apache; keepalive_timeoutin NGINX):

Wenn die Keep-Alive-Option aktiviert ist, wählen Sie ein längeres Keep-Alive-Timeout als den Leerlauf-Timeout des Lastenausgleichers.

Read Timeouts(requestReadTimeoutin Apache;client_header_timeoutundclient_body_timeoutin NGINX):
Legen Sie Read-Timeouts fest, die den Reaktionszeiten Ihrer Anwendung passen. Auf diese Weise stellen Sie sicher, dass Ihr Lastenausgleicher die Verbindung lange genug offen hält, um sowohl den Header als auch den Body der Anfrage zu empfangen.

**Warnung:**Stellen Sie sicher, dass der Wert für die Leerlaufzeit des Lastenausgleichers niedriger ist als der Back-End-Timeout.

Maximale Anzahl von Keep-Alive-Anfragen(MaxKeepAliveRequestsbei Apache;keepalive_requestsbei NGINX):
Diese Option legt fest, wie viele Anfragen eine einzelne TCP-Verbindung bedient, wenn Keep-Alive aktiviert ist. Um die Ressourcennutzung zu verbessern, legen Sie die maximale Anzahl von Keep-Alive-Anfragen auf 100 oder höher fest.

AcceptFilter(AcceptFilterbei Apache;akzeptiere_filterbei NGINX):
AcceptFilter ist standardmäßig aktiviert und weist Apache an, die Option TCP_DEFER_ACCEPT für die Verbindungen zu verwenden. Diese Einstellung kann dazu führen, dass sich der TCP-Socket in einem „halboffenen“ Zustand befindet. In diesem Zustand geht der Lastenausgleicher davon aus, dass die Verbindung hergestellt ist, aber die Backend-Instanz hat die Verbindung nicht hergestellt. Halboffene Verbindungen treten häufiger bei Lastenausgleichern mit geringem Datenvolumen auf, bei denen Verbindungen Zeit haben, zu altern, bevor sie verwendet werden.

Protokollierung:Aktivieren Sie die Option% {X-Forwarded-For}i, damit Apache den ELB-x-forwarded-for Header in seinen Protokollen für jede Anfrage anzeigt. Dieser Header enthält die IP-Adresse des ursprünglichen Clients. Die Option**%D**fügt den Zugriffsprotokollen die Zeit hinzu, die benötigt wird, um jede Anfrage abzuschließen:

LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b %D \"%{Referer}i\" \"%{User-Agent}i\"" combined

Apache: Das Apache-MPM (Multi-Processing-Module)-Ereignismodul kann Verbindungen von Lastenausgleichern vorzeitig schließen. Das vorzeitige Schließen von Verbindungen generiert HTTP 502-Fehler für den Anwendungslastenausgleich und HTTP 504-Fehler für den klassischen Lastenausgleich. Es hat sich bewährt, stattdessen das MPM-Arbeitsmodul zu verwenden, um dieses Verhalten zu verringern.

**Hinweis:**Nachdem Sie Ihre Konfiguration aktualisiert haben, starten Sie Apache oder NGINX neu.


Weitere Informationen

Registrierte Instanzen für Ihren klassischen Lastenausgleicher

Konfigurieren Sie Ihren klassischen Lastenausgleicher

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr