Ich habe eine Website auf Amazon Web Services, die mit Elastic Beanstalk bereitgestellt wird und auf mindestens zwei EC2-Mikroinstanzen ausgeführt wird. Eine Richtlinie für die automatische Skalierung ist vorhanden, sodass sie abhängig vom Traffic auf der Website skaliert und verkleinert werden kann. Aufgrund dieser automatischen Skalierungsrichtlinie wollte ich die Verwendung von Sticky-Sitzungen vermeiden. Aus diesem Grund verwende ich memcached-session- Manager . Ich verwende Amazon ElastiCache (kleine Instanz) für den Memcached-Server.
Die Konfiguration in der context.xml lautet wie folgt:
%Vor%Dies funktioniert gut, wenn der Datenverkehr gering ist (d. h. weniger als 10 Benutzer online), aber manchmal bewirkt, dass die EC2-Instanz neu gestartet wird. Sie können sich vorstellen, dass, wenn die Website derzeit auf zwei Instanzen läuft und beide gleichzeitig neu starten, die Website nicht mehr erreichbar ist und ein großes Problem darstellt. Dies sind die letzten Zeilen in der Datei "tail_catalina.log", die auf Amazon S3 rotiert wird, bevor die EC2-Instanz den Neustart annimmt:
%Vor%Es sieht so aus, als ob der Amazon ElastiCache-Knoten versagt, aber die Sache ist, dass ich bei Amazon CloudWatch sehen kann, dass die CPU-Auslastung nie über 8% ging. Gibt es einen Grund, warum der Amazon ElastiCache-Knoten ausfällt, obwohl er nicht so stark beansprucht wird? Warum entscheidet sich Amazon auch beim Neustart von Amazon ElastiChace (oder besser: Beenden und Starten einer neuen Instanz)?
Jede Hilfe wird sehr geschätzt.
Danke!
Sie sollten sessionBackupTimeout von memcached-session-manager erhöhen, indem Sie Dokumentation :
sessionBackupTimeout (optional, Standard 100)
Das Zeitlimit in Millisekunden nach dem eine Sitzungssicherung berücksichtigt wird als fehlgeschlagen. Diese Eigenschaft wird nur ausgewertet, wenn es sich um Sitzungen handelt synchron gespeichert (über sessionBackupAsync gesetzt). Der Standardwert ist 100 Millisekunden.