Shopware hat 4 verschiedene Session Handler/Adapter. Aber wann solltest du welchen einsetzen? Und welche Vorteile bietet dir welcher Session Handler?
Sessions
Sessions werden genutzt um User (Frontend = Shopkunden | Backend = Administratoren) für eine bestimmte Zeit Zugang zum Account oder Backend zu gewähren und bestimmte Daten (wie zum Beispiel Produkte im Warenkorb) zuzuordnen.
Beispiel s_order_basket
Hier sehen wir einen Screenshot mit der Session ID aus meinem Browser + Datenbankeinträge mit der Zuordnung in s_order_basket
Üblicherweise ist nun in s_core_sessions noch die Session ID hinterlegt – in meinem Fall ist diese leer, da ich Redis als Session Handler benutze, dazu später aber mehr.
Ihr könnt euch nun sicher vorstellen das, falls die Sessions in s_core_sessions abgelegt werden, hier eine Menge Last entsteht sobald sich einige Kunden auf dem Shop befinden.
Ich liste nun alle 4 Arten Sessions zu speichern auf – die langsamste zuerst und die schnellste zu Schluss.
File Session Handler
config.php
'session' => array(
'save_handler' => 'file',
),
'backendsession' => array(
'save_handler' => 'file',
),
Das verarbeiten der Session via File ist nur für wirklich kleine Shops zu empfehlen und selbst dann würde ich vermutlich das handeln über die DB vorziehen. Zum einen ist es nicht für mehrere Appserver (Cluster) geeignet, da die Files jeweils auf dem Appserver gespeichert werden und nicht zentral in der DB oder auf einem extra Server. Zum anderen entstehen bei einer langsamen SSD oder sogar HDD lange Wartezeiten.
Datenbank Session Handling
config.php
'session' => array(
'save_handler' => 'db',
),
'backendsession' => array(
'save_handler' => 'db',
),
Shopwares Standard Session Handler – kann Session Locking und ist für kleine Setups völlig ausreichend.
ab Version 5.2.13 ist es möglich das Session Locking abzuschalten (macht bei mehr Traffic Sinn)
'session' => array(
'save_handler' => 'db',
'locking' => false
)
Memcached Session Handling
config.php
'session' => array(
'save_handler' => 'memcached',
'save_path' => "localhost:11211",
),
'backendsession' => array(
'save_handler' => 'memcached',
'save_path' => "localhost:11211",
),
Wenn Ihr auf Performance Wert legt und einen Managed Hosting habt oder selbst einen Server verwaltet empfehle ich euch Memcached – die Installation ist einfach und Ihr werdet den Unterschied ab einem gewissen Traffic merken.
Obacht – mit Session Locking kann hier die Performance ähnlich sein wie mit dem DB Session Handling. Prüft vorab ausführlich ob euch Session Locking oder das abschalten des Lockings beeinflusst. In meinen Augen wird es von manchen völlig überzogen priorisiert. In den meisten Fällen hat es keinen negativen Einfluss auf die Funktionen des Shops.
Redis Session Handling
config.php
'session' => array(
'save_handler' => 'redis',
'save_path' => "tcp://127.0.0.1:6379",
),
'backendsession' => array(
'save_handler' => 'redis',
'save_path' => "tcp://127.0.0.1:6379",
),
Redis ist mein persönlicher Liebling – schnell, einfach aufzusetzen und man kann noch viele andere schöne Dinge damit machen, außer Session Handling (Shopware Enterprise unterstützt einen Redis HTTP Cache).
Das heißt, die Non-Enterprise unterstützt kein redis und man kann höchstens memcache verwenden?
Hi Jenny,
doch, die SW Community Edition unterstützt Standardmäßig das Session Handling über Redis.
Die Enterprise Version kann lediglich auch noch das HTTP Caching via Redis – ähnlich wie der Varnish Cache nur mit dem Vorteil, dass man für das handeln von ESI Tags und Cluster Setups kein Varnish Plus braucht (welches nochmal extra kostet).
Für mehr Info https://docs.enterprise.shopware.com/performance/essentials/#enterprise-cache-/-redis-cache
Hallo Micha!
Ich habe im Shopware Forum schon einen Thread erstellt (https://forum.shopware.com/discussion/51227/session-handling-eine-redis-instanz-fuer-zwei-shop-installationen), wollte hier aber auch nochmal direkt fragen: ist dir bekannt ob man auch zwei Shopware Installationen in eine Redis Instanz schreiben lassen kann, oder kommt es bei den Session IDs die in Redis als Key verwendet werden zu Kollisionen?
Vielen Dank übrigens für deinen tollen Artikel! 🙂
Hi Dennis,
freut mich das dir der Beitrag gefällt. Hast du mal getestet was passiert, wenn du den Namen deines Caches im Shop selbst änderst? Der Zend Cache hat neben save_path und save_handler noch name als Option.
Sprich für Shop1 dann ’name‘ => ’shop1′ in der jeweiligen Config und für Shop2 dann ’name‘ => ’shop2′
‚backendsession‘ => [
’save_handler‘ => ‚redis‘,
’save_path‘ => „tcp://127.0.0.1:6379“,
’name‘ => ’shop1′,
],
Der Cookie im Browser wird dann unter dem entsprechenden Namen angelegt und überschneidet sich nicht mehr. Aber wie gesagt mit Vorsicht zu genießen, NOT tested!
’save_path‘ => „tcp://127.0.0.1:6379?prefix=SHOP1_REDIS:“,
Damit wird in Redis der Prefix gesetzt, diesen kannst du dann für jeden Shop entsprechend in der Config anpassen
Die Doku zu weiteren Parametern findest du HIER
Habe das auch mal im Forum geschrieben.
Kann ich meine Plugins auch irgendwie über die Community Edition an die neue Quick View in der Enterprise Edition anpassen? Oder brauche ich dazu die Enterprise Edition? Danke
Hallo zusammen,
ich habe Redis im Einsatz und bekomme immer mal wieder Crojobs mit vielen anfragen wie zb. Produktexporte folgenden Fehler.
Hat jemand eine Ahnung woher das kommt?
Der Rest funktioniert ohne Probleme.
Fehler Log vom Cronjob
‚error‘ => ‚Zend_Session::start() – /var/www/vhosts/httpdocs/engine/Library/Zend/Session.php(Line:489): Error #2 session_start(): open(tcp://127.0.0.1:6379/sess_9b328b3738d6130c00fb80d589409872e190134c3ba2ccf91bbf1e0d0e9a41f1, O_RDWR) failed: No such file or directory (2)
/var/www/vhosts/httpdocs/engine/Library/Zend/Session.php(Line:499): Error #2 session_write_close(): open(tcp://127.0.0.1:6379/sess_9b328b3738d6130c00fb80d589409872e190134c3ba2ccf91bbf1e0d0e9a41f1, O_RDWR) failed: No such file or directory (2)
/var/www/vhosts/httpdocs/engine/Library/Zend/Session.php(Line:499): Error #2 session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (tcp://127.0.0.1:6379)‘