Warum sollten Sie MaxKeepAliveRequests auf etwas anderes als unbegrenzt setzen?
19121
Jonathon Reinhart
Apache ist KeepAliveTimeoutvorhanden, um eine Keep-Alive-Verbindung zu schließen, wenn innerhalb einer bestimmten Zeit keine neue Anforderung ausgegeben wird. Sofern der Benutzer seinen Browser / Tab nicht schließt, schließt dieses Zeitlimit (normalerweise 5-15 Sekunden) die meisten Keep-Alive-Verbindungen und verhindert, dass Serverressourcen verschwendet werden, indem Verbindungen auf unbestimmte Zeit gehalten werden.
Jetzt beschränkt die MaxKeepAliveRequestsDirektive die Anzahl der HTTP-Anforderungen, die eine einzelne TCP-Verbindung (offen gelassen wegen KeepAlive) offen lässt . Wenn Sie diese Option festlegen, 0ist eine unbegrenzte Anzahl von Anforderungen zulässig.
Warum sollten Sie dies auf etwas anderes als "unbegrenzt" setzen? Wenn ein Client noch aktiv Anfragen stellt, was ist dann der Schaden, wenn er dieselbe Keep-Alive-Verbindung passieren lässt? Sobald das Limit erreicht ist, werden die Anforderungen nur bei einer neuen Verbindung eingehen.
So wie ich es sehe, hat es keinen Sinn, dies einzuschränken. Was vermisse ich?
Grundsätzlich, weil Apache nicht dafür gebaut wurde. Das Problem ist die Serverspeicherverwendung. In vielen Konfigurationen erfolgt die Inhaltsgenerierung in demselben Prozess wie die Inhaltsbereitstellung. Daher wird jeder Prozess auf die Größe des größten Objekts vergrößert, für das er zuständig ist. Stellen Sie sich einen Prozess vor, der auf 64 MB durch ein umfangreiches PHP-Skript erweitert wird. Dann wird dieser aufgeblähte Prozess statisch abgespeichert. Multiplizieren Sie das jetzt mit 100. Wenn Speicherlecks irgendwo vorhanden sind, werden die Prozesse unbegrenzt wachsen.
Die Keepalive-Einstellungen sollten basierend auf der Art Ihres Inhalts und Ihres Datenverkehrs ausgewogen sein. Im Allgemeinen hat die optimale Konfiguration die Werte für MaxKeepAliveRequests (100-500) und KeepAliveTimeout (2-5), um sie schnell freizugeben.
1
lifeofguenter
Ich weiß, dass dies eine alte Frage ist, aber ich habe einiges debuggen, und es scheint, als ob (und das gilt nicht nur für Apache) MaxKeepAliveRequestsunabhängig von KeepAliveTimeout.
Das bedeutet, dass die Timeout-Direktive nur für im Leerlauf befindliche permanente Verbindungen gilt (keine Lese- oder Schreibvorgänge). Wenn Sie ständig unter dem Timeout anfordern, können Sie praktisch unbegrenzt viele Anfragen über dieselbe Verbindung ausführen.
Dies kann aus einigen Gründen nicht gut sein, einschließlich der Tatsache, dass langwierige TCP-Verbindungen zufällig abgebrochen werden? In jedem Fall sind http-Clients nicht so dumm und können eine "niedrige" MaxKeepAliveRequestsEinstellung ziemlich gut handhaben, z. B. ist es in der Programmiersprache relativ einfach zu erkennen, ob eine TCP-Verbindung vom Server geschlossen wurde und daher erneut eine Verbindung zu ihr herstellt. Darüber hinaus haben die meisten http-Clients eigene Beschränkungen (z. B. würden Browser nach etwa 300 Sekunden eine Keep-Alive-Verbindung schließen).
1
dtauzell
Ein Grund wäre der Lastausgleich. Sobald eine Keep-Alive- oder permanente HTTP 1.1-Verbindung hergestellt wurde, wird sie vom Load Balancer erst nach dem Schließen auf einen neuen Host verschoben. Wenn Sie über einen einzigen Client eine große Anzahl von Anforderungen über eine einzige Verbindung stellen, kann es sein, dass Sie keinen guten Ausgleich zwischen den Servern finden.
Aber warum sollte das wichtig sein? Es scheint mir nicht wünschenswert, die Verbindung eines einzelnen Benutzers über mehrere Server zu verteilen. Beim Lastausgleich handelt es sich um eine hohe Anzahl von Benutzern, nicht um Verbindungen von einem einzelnen Benutzer. In der Tat - wenn ein einzelner Benutzer einen Dienst hämmert, sollten Sie ihn lieber auf einen einzelnen Server beschränken (wo er sich selbst effektiv einschränken würde).
Jonathon Reinhart vor 7 Jahren
0
Gute Argumente. Ein paar Gedanken: 1. Jeder andere Server auf diesem Server wird ebenfalls gehämmert. 2. Für Load Balancer, die unterhalb der HTTP-Ebene arbeiten: Wenn Sie einen Server aus dem Load Balancer-Pool entfernen, wird die vorhandene HTTP-Verbindung nicht geschlossen. Dies macht es ein bisschen schwieriger, Personen nur mit dem Load Balancer auf einen anderen Server zu verschieben. Grund 2 ist der Grund, warum ich zu dieser Seite kam, während ich suchte, was die Leute über diesen Parameter zu sagen hatten.
dtauzell vor 7 Jahren
0
Ein dritter Grund: Wenn Ihr Server / Ihre Anwendung in einen fehlerhaften Zustand gerät und ausfällt, können durch das Anheften aller Anforderungen Fehler verursacht werden, bis die Situation korrigiert ist. Wenn Sie jedoch die Anzahl der Angriffe auf einen neuen Server begrenzen, kann dies zu Problemen führen .
dtauzell vor 7 Jahren
0
0
Elliott
Teilweise, um zu verhindern, dass ein einzelner Benutzer alle Verbindungssteckplätze belegt. Ohne Limit kann ein böswilliger oder schlecht geschriebener Client jede verfügbare Verbindung übernehmen und für immer behalten. Dies ist jedoch keine große Minderung, verglichen mit einer Beschränkung pro IP-Verbindung.
Meistens Lastausgleich, aber speziell in Bezug auf die Wartung. Wenn Sie einen Server offline schalten möchten, legen Sie ihn auf 0 Verbindungen ab, lassen jedoch zu, dass bestehende Verbindungen für einige Zeit beendet werden. Wenn die Anzahl der Keepalive-Anforderungen begrenzt wird, werden die Benutzer eventuell eine neue Verbindung erstellen und auf einen neuen Back-End-Server verschieben. Wahrscheinlich wäre eine Möglichkeit, dem Server zu signalisieren, dass er aufhören sollte, Keepalives während des Drain-Vorgangs vollständig zu akzeptieren, noch besser wäre, aber soweit ich weiß, gibt es eine solche Funktion nicht.