Wie lange müssen die Magento-Session-Dateien aufbewahrt werden?

Question

Ich habe einen Kunden, der Magento Session-Dateien sind schnell außer Kontrolle geraten. Wir reinigen sie einmal pro Woche, aber es scheint, dass es häufiger sein muss.

1) Was machen diese Dateien? Wie werden sie mit der Online-Erfahrung der Benutzer verbunden (z. B. wenn ich sie lösche und der Benutzer sich noch auf der Website befindet, wie werden sie betroffen sein)

2) Wie schnell kann ich sie löschen? Wie lange müssen die Dateien wirklich auf dem Server bleiben?

Chris

Answer 1

Jede Datei Sitzung eine Person ist und sollte zuletzt nicht mehr als session.gc_maxlifetime Sekunden - die Garbage-Collection - wird in der php.ini-Datei des Servers festgelegt oder in einer .htaccess-Datei überschrieben. Wenn Sie diesen Wert verringern, werden weniger Sitzungen angesammelt.

Magento hat einen anderen Trick in Bezug auf Sitzungen; In der Datei /app/etc/local.xml kann der Wert session_save in db geändert werden, was bedeutet, dass die Datenbank anstelle von Dateien verwendet wird, aber dennoch die oben genannte Lebensdauer des Garbage Collectors berücksichtigt wird. Auch memcache kann angegeben werden, wenn Sie dies eingerichtet haben (siehe /app/etc/local.xml.additional). Beide sind sehr nützlich, wenn der Server ein Cluster ist.

Answer 2

hängt von Ihrer Lebensdauer einer Sitzung, wenn die Sitzungen gehalten Benutzer oder seine Vorlieben angemeldet bleiben intakt bleiben, wenn wieder den Laden zu besuchen. Sie können sie löschen, so oft wie Sie aber daran erinnern, dass es sich abzumelden wird/clear Karren für alle Benutzer, die angemeldet sind, während Sie es tun

Answer 3

Vergessen Sie nicht, in den Teil des Systems zu schauen, der unangemessene Datenmengen in der Sitzung falsch speichert, um das Problem zu beheben. Das frühere Löschen von Sitzungen ist nur eine vorübergehende Lösung.

Sitzungsdateien sollten immer klein bleiben. Odds sind, einige Skript speichert eine unangemessen große Menge an Daten in der Sitzung für "Effizienz" und verursacht das Problem.

---

Es ist fast sicher, dass Objekte in der Sitzung gespeichert werden, die dieses Problem verursachen. Ein übliches Muster ist in Magento Objektdaten, wie diese verkettet haben:

$product-> 
    'attr1' => 'somevalue', 
    ... 
    'categories' => array(
     'products' => array(
     <and so on and so forth> 
     ), 
    ), 

ein Objekt in der Session Dropping kann diese gigantische Ketten von Objekten unbeabsichtigt umfassen viele irrelevante Daten zu speichern. Speichern Sie nach Möglichkeit nur Zeichenfolge/numerische Daten in der Sitzung, z. B. Arrays von IDs für Produkte und nicht die Produkte selbst.

Answer 4

Bei dateibasierten Sitzungen werden sie automatisch vom PHP-Sitzungs-Bereinigungs-Cron bereinigt, sodass die Dateien wahrscheinlich innerhalb von ~ 7200 Sekunden nach der Erstellung gelöscht werden. Selbst auf einer belebten Seite (30k Uniques pro Tag) gibt es normalerweise nur etwa 4.000 Sitzungsdateien in ./var/session - was nichts für einen Linux-Server ist.

Allerdings hängt die Bereinigung tatsächlich von der Cron-Funktion ab - die normalerweise nicht im Verzeichnis ./var/session von Magento aussieht. So sollten Sie ein neues System cron

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1 

Der Standard aufzuräumen Zeit für Sitzungen einrichten 7200 Sekunden, was mehr als ausreichend sein sollte, obwohl Sie die oben ändern können angepasst werden.

Mit Memcache-Sitzungen ist TCP/IP der einzige Overhead, der für eine Einzelserverbereitstellung langsamer als dateibasiert ist. Dann würden Sie stattdessen einen Unix-Socket verwenden, der diesen Overhead beseitigt und bessere Sicherheit bietet. Aber auch Ihre Kundensitzungen werden gekürzt/eingeschränkt, was die Menge an Arbeitsspeicher betrifft, die Sie zuweisen können. Die durchschnittliche Magento-Sitzung ist 4 KB - so können Sie 256 aktive Sitzungen pro zugewiesenem MB unterstützen. Stellen Sie also sicher, dass Sie ein angemessenes Limit festlegen, um zu vermeiden, dass Kunden den Warenkorb/die Sitzung zufällig verlieren. Bedenken Sie auch, dass ein Memcache-Daemon-Neustart alle vorhandenen Sitzungen löscht (BAD!).

Mit Redis (nicht nativ, aber über eine Erweiterung verfügbar) erhalten Sie eine ähnliche Unterstützung wie Memcache, aber mit den zusätzlichen Vorteilen der Persistenz (falls Sie es verwenden möchten). Mit der Cm_Redis-Erweiterung können Sie auch die Sitzungskomprimierung nutzen. Wir haben festgestellt, dass diese Erweiterung sowohl bei CE- als auch EE-Bereitstellungen sehr gut funktioniert.

Mit der DB ist die Standard-Ablaufeinstellung für die Wiederherstellung eine mächtige 1 Woche, also mit der obigen Speichergröße als Beispiel (30k Uniques pro Tag), werden Sie eine DB-Tabellengröße für core_cache_session von etwa 7GB betrachten - was Ihren Laden für fast jeden sitzungsbasierten Betrieb zum völligen Stillstand bringt.

Aus der Erfahrung von Hosting sowohl große (230k Besucher pro Tag) und kleine (< 1k Besucher pro Tag) speichert, unsere Empfehlung:

Einzelserverbereitstellung - Dateien

Multi -server Einsatz - Redis (eine separate Datenbank aus dem Haupt Magento-Cache)

ich schrieb ein paar wirklich gründliche Antworten hier http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

Answer 5

Ich hatte sie auch angehäuft, also fügte ich einen Cron-Job mit dem folgenden hinzu ... (das war von den Anweisungen in meiner php.ini-Datei ... gerade unter der "session.gc_maxlifetime = 1440" -Einstellung)

Für Beispiel: Das folgende Skript entspricht ; Setzen von session.gc_maxlifetime auf 1440 (1440 Sekunden = 24 Minuten): ; finde/pfad/zu/sessions -cmin +24 | xargs rm