Under the hood: OXID eShop EE Caching und die SOAP-Schnittstelle

Über das Caching in der OXID EE gab es an dieser Stelle ja schon einige Informationen. So ein Cache, egal ob auf Datei- oder z.B. Memcached-Basis, sollte natürlich möglichst lange vorhalten, um optimale Performance zu gewährleisten.

Im OXID eShop gibt es zahlreiche Aktionen, die ein (teilweises) Leeren des Caches zur Folge haben. Neben Verkäufen im Shop und damit verbundenen Lagerbestandsänderungen usw. können dies auch diverse Aktionen im Shop-Administrationsbereich sein. So empfiehlt es sich im Normalfall generell, im Shop-Admin unter „Performance“ die Checkbox „Cache nur beim Ausloggen aus dem Administrationsbereich leeren“ („blClearCacheOnLogout“ im Code) zu aktivieren, um ein Löschen des gesamten Caches zu verhindern, wenn man im Admin z.B. Shopeinstellungen bearbeitet, Benutzerdaten ändert usw. In der OXID EE muss dies natürlich pro Mandant aktiviert sein. Ein weiterer „Cache-Killer“ kann übrigens die Performance-Einstellung „Ähnliche Artikel anzeigen“ sein – hier wird im Falle eines Artikel-Verkaufs im Shop ebenfalls großzügig der Cache geleert, wenn es ähnliche Artikel (zu einem definierbaren Prozentsatz übereinstimmende Attribute) im Shop gibt.  Wenn man dieses Feature nicht zwingend benötigt und den EE Cache nutzt, sollte man darauf ggf. verzichten und die Checkbox deaktivieren.

Kommt nun aber die SOAP-Schnittstelle von OXID im Zusammenhang mit mehreren OXID EE Mandanten ins Spiel wird es generell „lustig“ 🙂 Die SOAP-Schnittstelle „vergisst“ gerne einmal an unterschiedlichen Stellen, die korrekte Shop-ID zu setzen und ruft bestimmte Methoden ohne Shop-ID auf… so kann es vorkommen, dass man zwar per SOAP eingeloggt ist und auch brav die Shop-ID gesetzt hat, die Schnittstelle aber dann dennoch Konfigurationseinstellungen o.ä. aus dem Hauptshop mit der Shop-ID 1 liest.
So konnten wir bei mehreren Kunden das Phänomen beobachten, dass bei jedem Update über die SOAP-Schnittstelle (was in der Regel alle paar Minuten auftrat) der komplette Cache gelöscht wurde, wodurch das Caching natürlich nahezu hinfällig wurde. Die Lösung des Rätsels war, dass die SOAP-Schnittstelle einerseits ein Admin-Login im Shop simuliert und andererseits oben skizzierter Bug auftrat, nämlich dass die Admin-Einstellungen nicht wie erwartet von Shop-ID 6, sondern vom Default-Shop gelesen wurden, obwohl beim SOAP-Connect ordnungsgemäß die Shop-ID gesetzt worden war. Tief unten im Shopcode, genauer gesagt in der Methode oxbase::save() wurde nun oben erwähntes Flag „blClearCacheOnLogout“ abgefragt, das aber natürlich nur im Shop mit der ID 6 gesetzt war – und so wurde nach dieser vermeintlichen „Admin-Aktion“ jedesmal der komplette Cache gelöscht.

Für einen schnellen Fix einfach auch im Shop 1 die erwähnte Checkbox aktivieren (und ggf. auch andere wichtige Einstellungen, man weiß ja nie …), wenn man Probleme mit Caching im Zusammenspiel mit der SOAP-Schnittstelle bei Enterprise Mandanten hat 🙂

 

0.00 avg. rating (0% score) - 0 votes


0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.