Ich habe einen Kunden, dessen Magento Session-Dateien 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 hängen sie mit der Online-Erfahrung der Benutzer zusammen (z. B. wenn ich sie lösche und der Benutzer sich noch auf der Website befindet, wie werden sie davon betroffen sein?)
2) Wie schnell kann ich sie löschen? Wie lange müssen die Dateien wirklich auf dem Server bleiben?
Chris
Jede Datei ist die Sitzung einer Person und sollte nicht länger 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 weiteren Trick in Bezug auf Sitzungen; In der Datei /app/etc/local.xml kann der session_save -Wert 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.
Bei dateibasierten Sitzungen werden sie automatisch vom PHP-Sitzungs-Bereinigungs-Cron bereinigt - so werden die Dateien wahrscheinlich innerhalb von ~ 7200 Sekunden nach der Erstellung gelöscht. Selbst auf einer belebten Seite (30k Uniques pro Tag) gibt es normalerweise nur ungefähr 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. Also sollten Sie ein neues System cron einrichten
%Vor%Die Standardbereinigungsperiode für Sitzungen beträgt 7200 Sekunden. Dies sollte mehr als ausreichend sein, Sie können jedoch die oben genannten Einstellungen ändern.
Bei Memcache-Sitzungen ist TCP / IP der einzige Overhead, der bei einer Einzelserverbereitstellung langsamer als auf einer Datei 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 in CE- als auch in EE-Bereitstellungen sehr gut funktioniert.
Bei der DB ist die Standard-Einstellung für den Ablauf der Ablaufzeit eine mächtige Woche. Wenn Sie also beispielsweise die obige Geschäftsgröße verwenden (30.000 Uniques pro Tag), sehen Sie sich eine DB-Tabellengröße für core_cache_session von etwa 7 GB an. was für fast jede sitzungsbasierte Operation Ihren Laden zum völligen Stillstand bringt.
Aus Erfahrung mit dem Hosting großer (230.000 Besucher pro Tag) und kleinen (& lt; 1k Einzelbesucher pro Tag) Shops empfehlen wir:
Einzelserverbereitstellung - Dateien
Multi-Server-Bereitstellung - Redis (mit einer separaten Datenbank aus dem Magento-Hauptcache)
Ich habe hier einige wirklich gründliche Antworten geschrieben. Ссылка
hängt von der Lebensdauer Ihrer Sitzung ab. Wenn die Sitzungen beibehalten werden, bleibt der Benutzer angemeldet oder seine Einstellungen bleiben beim erneuten Besuch des Geschäfts erhalten. Sie können sie löschen, so oft Sie möchten, aber denken Sie daran, dass sie die Wagen für alle angemeldeten Benutzer abmelden / löschen wird, während Sie dies tun
Vergessen Sie nicht, in den Teil des Systems zu schauen, der unangemessene Datenmengen in der Sitzung falsch speichert, um das Problem tatsächlich 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 gängiges Muster in Magento ist, dass Objektdaten wie folgt verkettet werden:
%Vor%Wenn ein Objekt in die Sitzung eingefügt wird, können unbeabsichtigt diese riesigen Objektketten eingeschlossen werden, die viele überflüssige Daten speichern. Speichern Sie nach Möglichkeit nur String- / numerische Daten in der Sitzung, z. B. Arrays von IDs für Produkte und nicht die Produkte selbst.
Ich habe sie auch angehäuft, also habe ich einen Cron-Job mit folgendem hinzugefügt ... (das kam aus den Anweisungen in meiner php.ini-Datei ... gerade unter der Einstellung "session.gc_maxlifetime = 1440")
Zum Beispiel wäre das folgende Skript das Äquivalent von ; Setzen von session.gc_maxlifetime auf 1440 (1440 Sekunden = 24 Minuten): ; finde / pfad / zu / sessions -cmin +24 | xargs rm