Wie lange ist die magento session-Dateien aufbewahrt werden müssen?

Dateisystem-basierte Sitzungen, Sie werden automatisch beschnitten werden, indem die PHP-session clean-up-cron – also die Dateien sind wahrscheinlich zu sein gelöscht innerhalb von ~7200 Sekunden der Schöpfung. So auch an einem geschäftigen Ort (30k uniques pro Tag), gibt es in der Regel nur rund 4.000 session-Dateien in ./var/session – das ist nichts für einen Linux-server.

Jedoch der clean-up-tatsächlich beruht auf der cron-arbeiten - die nicht normalerweise sehen die in der ./var/session-Verzeichnis von Magento. So sollte man 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

Den Standard-clean-up-Periode für die Sitzungen 7200 Sekunden, das sollte mehr als ausreichend, Sie können zwar ändern, die oben zur Klage.

Mit Memcache-Sitzungen, TCP/IP ist das nur overhead, was für eine Bereitstellung auf einem einzelnen server würde es langsamer als Datei basiert. Also dann, würden Sie einen unix-socket statt, was entfernt, die Aufwand und gibt mehr Sicherheit. Aber sogar noch, Ihre Kunden-sessions werden abgeschnitten/begrenzt auf die Menge an RAM, die Sie zuordnen können. Die Durchschnittliche Magento session ist 4Kb – so werden Sie in der Lage, Unterstützung von 256 aktiven Sitzungen pro MB, die Sie zuordnen. So sicher sein, stellen Sie ein entsprechendes limit zu vermeiden, die Kunden nach dem Zufallsprinzip zu verlieren, cart/Sitzung. Und auch Bedenken, ein Memcache-daemon neu gestartet wird abwischen alle vorhandenen Sitzungen (SCHLECHT!).

Mit Redis (nicht native, sondern über eine Erweiterung), erhalten Sie einen gleichwertigen support wie Memcache, aber mit dem zusätzlichen Vorteil der Persistenz (sollten Sie wünschen, es zu benutzen). Mit der Cm_Redis-Erweiterung, Sie werden auch in der Lage sein, um die Vorteile von session-Kompression. Wir haben festgestellt, diese extension funktioniert sehr gut sowohl auf CE und EE-Implementierungen.

Die mit der DB, die Standard-prune Ablauf Einstellung ist eine mächtige 1 Woche, also mit der oben genannten Größe des Ladens als ein Beispiel (30k uniques pro Tag), werden Sie mit Blick auf eine DB-Tabelle Größe für core_cache_session von rund 7GB – die Schleifen Ihren Shop zu einem kompletten Stillstand für fast jeden session-basierten Betrieb.

Aus der Erfahrung des hosting - beiden großen (230k Besucher pro Tag) und klein (<1k Besucher pro Tag) speichert, ist unsere Empfehlung:

Single-server Bereitstellung - Dateien

Multi-server-Bereitstellung - Redis (mit einer separaten Datenbank von den wichtigsten Magento-cache)

Schrieb ich eine wirklich Gründliche Antworten hier http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

Vergessen Sie nicht, zu schauen, was Teil des Systems nicht ordnungsgemäß speichern unangemessene Mengen von Daten in die session, um tatsächlich das problem zu beheben. Clearing-Sitzungen früher ist nur eine temporäre Lösung.

Session-Dateien sollten immer klein bleiben. Chancen sind, werden einige Skript speichert eine unangemessen große Menge von Daten in der session zu "Effizienz" und das problem verursacht.

Es ist fast mit Sicherheit für Objekte in der session gespeichert dieses problem verursacht. Ein gemeinsames Muster in Magento ist Objektdaten gefesselt wie dieses:

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

Ablegen eines Objekts in der session können diese riesigen Ketten von Objekten unbeabsichtigt, speichern viele überflüssige Daten. Wenn möglich, speichern Sie nur string-und numerischen Daten in der session, wie arrays von IDs für Produkte, anstatt die Produkte selbst.