Hallo zusammen,
wir haben ein Cluster Setup und nutzen den HTTP Cache. Um genau zu sein haben wir 2 Server fe01.domain.tld und fe02.domain.tld. Anfragen werden über einen Loadbalancer auf beide verteilt. Auf beiden Server ist jeweils der Shopware eigene HTTP-Cache aktiviert. Nach leere ich den Cache und wärme ihn neu auf. Nach dem Aufwärmen des Caches sind beide Cache Verzeichnisse etwas gleich groß. 5,4GB und 5,5GB. Für meine dafürhalten sollten die eigtl gleich so sein. Aber das ist ein anderes Thema. Über den Tagesverlauf wird der Cache auf FE01 immer kleiner. Vor dem Cache Warming ist er nur noch wenige Megabyte groß, währned der Cache auf FE02 annährend gleich groß bleibt.
Ich suche nun schon verzweifelt nach einer Erklärung dafür. Finde aber keine. Ich habe schon das Absetzen und Empfangen der BAN Requests in Shopware geloggt. Bei FEs bekommen die selben BAN Requests. Auch das Löschen/purgen der Dateien aus dem Cache Verzeichnis habe ich protokolliert. Das sieht zwar nicht 1:1 gleich aus, die Unterschiede erklären aber auch nicht die Abweichung von mehren Gigabyte.
Hat jemand von euch noch eine Idee oder schonmal ein ähnliches Problem?
Ich bin auf das Problem gekommen, da ich ferstgestellt habe, dass nicht mehr alle Anfragen auf dem Cache beantwortet werden, obwohl sie das eigtl sollten.
VG Arne
Es gibt generell keinen “Auräum-Prozess” für Caches - also keine Mechanik die begründen würde, warum der Cache kleiner wird. Er müsste, ohne das jemand ihn leert, immer größer werden - das bedingt ja die automatische invalidierung, die Dateien bleiben ja auch invalide im Cache-Verzeichnis.
config.php ist auf beiden Servern gleich?
Generell würde ich bei so einem Setup ab 5.3 immer Redis als Cache-Storage empfehlen, damit hat man halt einen Cache für beide Appserver und spart sich die Probleme die zwei unterschiedliche Caches haben (bspw. asynchrone Cache-Stände).
Redis könnten wir leider nicht als Storage für den HTTP Cache nutzen, da wir keine Enterprise Lizenz haben *hust*.
Ich habe im Code halt auch keinen „Aufräum Prozess“ gefunden. Außer die Invalidierung über BAN/PURGE Requests.
Die config.php ist, bis auf die Datenbank Config, identisch. Die restliche Code Basis natürlich auch.
Ich habe jetzt nochmal auf Betriebssystem Ebene einen Filewatcher laufen. Dann kann ich die gelöschten Dateien mit den gelöschten Dateien aus den Shopware Logs abgeichen. Vielleicht löscht ja gar nicht Shopware, sondern ein anderer Prozess.
Ansonten wird mir wohl nur überbleiben auf Enterprise zu updaten und Redis als Storage zu nehmen oder einen Varnish davor zu bauen.
Werden die ESIs vom Symfony HTTP Cache eigtl seriel oder parallel abgerufen? Varnish ruft sie ja soweit ich weis seriel ab, und Varnish Plus parallel? Und gibt es eine Faustregel ab wieviel ungecachten ESIs der Shopware HTTP Cache schneller ist als Varnish?
Naja den Varnish dürftest du eig. auch erst ab Enterprise einsetzen 
Dabei geht es ja erstmal nur um den Support, wir geben Support für Varnish, Elasticsearch, Redis nur in der Enterprise-Version. Der Einsatz selbst wird dadurch ja garnicht geregelt. Der Einsatz von Redis ist ab 5.3 ja Core-Bestandteil: config.php settings
Ich bin kein Fan von Varnish - zum einen erhöht der die Komplexität und gerade in ungecachten Bereichen (bspw. Checkout) haben wir auch in großen Projekten schon häufig mit komischen Performance-Engpässen zu kämpfen gehabt. Du könntest ja bspw. mit Tideways ganz gut überwachen wie lange deine ESI-Calls laufen und ob diese ggf. zu langsam sind.
Dabei geht es ja erstmal nur um den Support, wir geben Support für Varnish, Elasticsearch, Redis nur in der Enterprise-Version. Der Einsatz selbst wird dadurch ja garnicht geregelt. Der Einsatz von Redis ist ab 5.3 ja Core-Bestandteil: https://developers.shopware.com/developers-guide/shopware-config/#redis-configuration
Ich dachte, dass bezieht sich nur auf den Backend Cache. Für mich wird auf dem Artikel leider nicht klar, dass das für sämtliche Caches gilt?!?
Generell würde ich bei so einem Setup ab 5.3 immer Redis als Cache-Storage empfehlen, damit hat man halt einen Cache für beide Appserver und spart sich die Probleme die zwei unterschiedliche Caches haben (bspw. asynchrone Cache-Stände).
Ich dachte die Aussage bezieht sich auf das Essentials Plugin für die Enterprise. Da ist ja auch explizit von einem Redis HTTP Cache die Rede.
Ich bin kein Fan von Varnish - zum einen erhöht der die Komplexität und gerade in ungecachten Bereichen (bspw. Checkout) haben wir auch in großen Projekten schon häufig mit komischen Performance-Engpässen zu kämpfen gehabt. Du könntest ja bspw. mit Tideways ganz gut überwachen wie lange deine ESI-Calls laufen und ob diese ggf. zu langsam sind.
Dann sind wir schon zwei. Ich habe auch keine Lust den Varnish zu konfigurieren ;)