Was sind die optimalen Einstellungen, die ich für Apache oder NGINX als Backend-Server für ELB verwenden kann?
Ich möchte eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance mit Apache oder NGINX als Backend-Server für Elastic Load Balancing (ELB) verwenden. Ich möchte wissen, welche Einstellungen die beste Leistung bieten.
Lösung
Um die beste Leistung zu erzielen, analysiere die Reaktionszeiten deiner Backend-Anwendung und die Anforderungen deiner Kunden.
Timeout beim Client-Header
Wenn der Backend-Server eine Verbindung schließt und den Load Balancer nicht benachrichtigt, erhältst du möglicherweise einen HTTP-502-Fehler für einen Application Load Balancer. Bei einem Classic Load Balancer erhältst du einen HTTP-504-Fehler.
Um Verbindungsleerlauf zu verhindern, stelle das Anwendungs-Timeout auf einen Wert ein, der höher ist als der Wert für das Leerlauf-Timeout. Informationen zur Konfiguration des Anwendungs-Timeouts für Apache siehe TimeOut-Direktive auf der Apache-Website. Was NGINX betrifft, siehe client_header_timeout auf der NGINX-Website.
Keepalive-Funktion
Aktiviere die Keepalive-Funktion, um die CPU-Auslastung zu reduzieren und die Antwortzeit zu verbessern. Bei aktivierter Keepalive-Funktion baut der Load Balancer nicht für jede HTTP-Anfrage eine neue TCP-Verbindung auf.
Informationen zum Aktivieren von Keepalive für Apache siehe KeepAlive-Direktive auf der Apache-Website. Aktiviere Keepalive in NGINX, indem du keepalive_disable auf none einstellst. Weitere Informationen siehe keepalive_disable auf der NGINX-Website.
Wenn du die Keepalive-Option aktivierst, achte darauf, dass das Keepalive-Timeout länger ist als das Leerlauf-Timeout des Load Balancers. Informationen zur Konfiguration des Timeouts in Apache siehe KeepAliveTimeout-Direktive auf der Apache-Website. Was NGINX betrifft, siehe keepalive_timeout auf der NGINX-Website.
Lese-Timeouts
Lege Read-Timeouts fest, die den Reaktionszeiten deiner Anwendung passen. Der Load Balancer muss die Verbindung lange genug offen halten, um sowohl den Header als auch den Text der Anfrage zu empfangen.
**Hinweis:**Stelle sicher, dass der Wert für die Leerlaufzeit des Lastenausgleichers niedriger ist als der Back-End-Timeout.
Informationen zum Einstellen des Lese-Timeouts für Anfragen in Apache siehe RequestReadTimeout-Direktive. Informationen zum Einstellen des Client-Header-Timeouts in NGINX siehe client_header_timeout auf der NGINX-Website. Informationen zum Client-Text-Timeout in NGINX siehe client_body_timeout auf der NGINX-Website.
Maximale Anzahl von Keepalive-Anfragen
Stelle bei der Aktivierung der Keepalive-Funktion die Anzahl der Anfragen, die eine einzelne TCP-Verbindung bedient, auf mindestens 100 ein. Informationen zum Einstellen der Anzahl der Anfragen in Apache siehe MaxKeepAliveRequests-Direktive auf der Apache-Website. Was NGINX betrifft, siehe keepalive_requests auf der NGINX-Website.
AcceptFilter
Standardmäßig ist AcceptFilter aktiviert. AcceptFilter weist Apache an, die Option TCP_DEFER_ACCEPT für die Verbindungen zu verwenden, was dazu führen kann, dass der TCP-Socket in einem halb geöffneten Zustand verbleibt. Wenn der TCP-Socket im halboffenen Zustand verbleibt, geht der Load Balancer davon aus, dass die Verbindung hergestellt ist, aber die Backend-Instance stellt die Verbindung nicht vollständig her. Halboffene Verbindungen treten häufiger bei Load Balancern mit geringem Volumen auf, bei denen Verbindungen vor der Verwendung inaktiv sind.
Informationen zur Konfiguration von AcceptFilter in Apache siehe AcceptFilter-Direktive auf der Apache-Website. Was NGINX betrifft, siehe listen auf der NGINX-Website.
Protokollierung
Aktiviere die Option %{X-Forwarded-For}i, damit Apache den ELB x-forwarded-for-Header in seinen Protokollen für jede Anfrage anzeigt, mit folgendem Befehl:
LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b %D \"%{Referer}i\" \"%{User-Agent}i\"" combined
Der ELB x-forwarded-for-Header enthält die IP-Adresse des ursprünglichen Clients. Die Option %D fügt den Zugriffsprotokollen die erforderliche Zeit hinzu, um jede Anfrage abzuschließen.
Apache MPM
Das Apache Event Multi Processing Module (MPM) schließt möglicherweise vorzeitig Verbindungen von Load Balancern und verursacht einen HTTP-502-Fehler für einen Application Load Balancer. Bei einem Classic Load Balancer wird der Fehler HTTP 504 ausgegeben.
Es hat sich bewährt, stattdessen das Worker MPM zu verwenden.
**Hinweis:**Nachdem Sie Ihre Konfiguration aktualisiert haben, starten Sie Apache oder NGINX neu.
Weitere Informationen
Registrierte Instanzen für Ihren klassischen Lastenausgleicher
- Sprache
- Deutsch

Relevanter Inhalt
AWS OFFICIALAktualisiert vor 3 Jahren
AWS OFFICIALAktualisiert vor einem Jahr