Im Shop verwalten wir so einige Kunden über Kundengruppen zwecks Preise und auch gibt es Kategorien, die nur für manche Kundengruppen bestimmt sind.
Der Seitenaufbau ist so langsam sobald man sich mit einer anderen Kundengruppe anmeldet, das ist wirklich für die Kunden nicht zumutbar. Grund hierfür ist wohl das Caching, da es für die Kundengruppen nicht vorgesehen ist und erst gecached wird, wenn man eine Kategorie öffnet. Aber, auch das scheint nicht zu 100% haften zu bleiben. Ich gehe davon aus, dass durch unsere Wawi (JTL), die alle 3 Minuten Preise und Bestände abgleicht, der Cache teilweise für die Kundengruppen flöten geht.
Habt ihr einen Vorschlag oder einen Tipp, wie man dem Ganzen ein wenig entgegen wirken kann?
Ich habe mich schon mehrfach belesen und rumprobiert, aber anscheinend gibt hierfür noch keine Lösung.
Wir machen es mit den Preisen über die Kundengruppen genauso: gibt ne Menge Kundengruppen. Wir schränken jedoch die Artikel oder Artikelkategorien nicht nach Kundengruppe ein. Bei uns läuft es ganz normal schnell.
Unsere WaWI gleich jedoch nicht so häufig die Preise und Bestände ab (wird das überhaupt innerhalb von 3 Minuten geschafft bei vielen Artikeln?)
Daher meine Empfehlung mal testen:
keine Einschränkung der Artikel/Artikelkategorien
Update der Preise / Lagerbestände nicht so häufig (reicht nicht auch stündlich, alle 2 Stunden, alle 4 Stunden?)
wenn das alles nicht hilft: wie groß ist dein Hosting Tarif? Muss vielleicht was schnelleres her?
Datenbank Typ und Version?: Bei vielen Preisen und Kundengruppen kann vielleicht die Datenbank zu langsam sein. Macht ein Unterschied MySQL 5.6 oder MariaDB 10.3 zu verwenden.
vielen Dank für deine Antwort. Wir haben aktuell Shopware 5.6.3. am laufen.
Unser Hoster sind ist Timmehosting. Wir haben dort einen Managed Server mit 12 Kerne, 64GB Ram, 400GB NVMe-SSD mit nginx. Also ich denke das passt soweit schon.
Dazu müsste man wissen wie hoch die caches gesetzt sind und welche/wie mit welchen Parametern eingebunden sind. An der Leistung der DB kann man sicher auch noch schrauben.
Am besten Du setzt dich mit genau diesen Fragen, die Du gestellt hast mit Timmehosting in Verbindung; Die solten genau wissen was die für Dich tun können.
vielen Dank für eure Vorschläge. Hatte alles schonmal durch. Meine letzte Hoffnung ist jetzt erstmal Timme, denn die hatte ich auch noch parallel angeschrieben. Mal sehen was dabei rauskommt.
Werde euch dann berichten, ob es eine Lösung gibt.
Ich habe jetzt mal so einiges durchgetestet und es bleibt immer das gleiche. Es ist auch egal, ob in der Kategorie nur 1 Artikel vorhanden ist, die Ladezeit bleibt extrem lang.
Timme wird erstmal ein MariaDB update durchführen. Außerdem werden sie noch ein paar Buffer Einstellungen an der Datenbank vornehmen, wodurch wahrscheinlich ein wenig Performance dazu kommt. Ich habe an Timme noch ein paar Tideway Screenshots gesendet und die wollten da mal drüber schauen.
Es hat auf jeden Fall etwas mit dem „Controller Frontend Listing Proxy“ zutun und die dazugehörige Anfrage zur Datenbank.
Timme hatte auch noch angeraten den Redis Cache zu aktivieren, um die Datenbank und Server zu entlasten. Problem ist hierbei, der JTL-Connector unterstützt kein Redis, also sind wir hier erstmal aufgeschmissen.
Wenn sich durch die Datenbankanpassungen nichts ändert, werde ich heute Abend mal die Datenbank auf einen anderen Server schmeißen, mal sehen ob man dadurch eine Performance Verbesserung erreichen kann.
Um 10 Uhr wird das Update durchgeführt. Bericht kommt dann.
Im übrigen wurde das MariaDB Update durchgeführt und eine Bufferanpassungen. Resultat, die Kategorien laden ca. 4 sek. schneller. Jetzt sind es nur noch 11 Sekunden anstatt 15-16.
Heute Abend hau ich die Datenbank mal auf einen anderen Server. Mal sehen ob es was bringt.
ich habe jetzt nochmal was gefunden. Es hat definitiv was mit dem Filter im Listing zutun, denn nach abschalten des Preisfilters wurde die Aufrufzeit nochmal um 5 Sek. Reduziert.
Jetzt sind wir ca. bei 5-6 Sekunden.
Kennt sich jemand mit elasticsearch aus? Könnte das eventuell Abhilfe schaffen?
finde es ehrlichgesagt schade, dass sich Shopware selbst nicht zu solchen Sachen äußert. Ich verstehe nicht, was da so anders ist, wenn ich mich mit einer anderen Kundengruppe einlogge. Die Abfrage bleibt ja die gleiche. Bei Kundengruppe “Shopkunde”, wird in der Datenbank der Preis für Kundengruppe “Shopkunde” abgefragt. Bei Kundengruppe “XYZ” wird der Preis von Kundengruppe “XYZ” in der Datenbank abgefragt. Also was läuft da anders?
Wenn ich den Cache lösche vom Shop, dann müsste doch die erste Anfrage für den “Shopkunden” genau so lange dauern in den Kategorien, weil noch nichts gecached ist oder nicht? Es ist aber definitiv nicht so. Verstehe es nicht. Was ist da anders?
Es ist im übrigen egal was ich nutze, Elasticsearch oder Redis cachen anscheinend nur die Standard Kundengruppe.
Gibt es da in der 6er Version ein Umdenken in Richtung Kundengruppen und Caching?
@redheadman Du bewegst Dich hier im kostenlosen Forum von User zu User; Wenn Du echten Support von Shopware willst, wirst Du dafür zahlen müssen.
Du scheinst noch recht Neu in diesem Bereich zu sein, sodass Deine Lernkurve bezüglich der Frustration sicher noch ein wenig Luft nach oben hat Insbesondere dann mit Shopware 6
Nicht wirklich Neu, bin schon ein paar Jahre mit Shopware unterwegs, aber bis jetzt wirklich ohne jegliche bzw. nicht so deutlich frustierende Probleme.
Habe bis jetzt nur Gutes von der 6er gehört und auch deswegen die Finger davon gelassen.
Aber auf jeden Fall hast du heute meinen Tag gerettet. Danke dafür
Zu User helfen User hat kulli ja schon alles gesagt, auch zum Frustfaktor Wobei ich aber zunehmend das Gefühl habe, dass Shopware an diese “unsere” Gruppe der Community nicht mehr sonderlich interessiert ist.
Zur Aussage, es müsse doch egal sein, welche Kundengruppe abgefragt wird: Nein, es ist nicht egal!
Dem Shop ist in den Einstellungen eine Kundengruppe vorgegeben. Für diese Kundengruppe müssen alle Preise hinterlegt sein. Mache ich nun eine Abfrage auf diese Kundengruppe, wird die Abfrage recht einfach. Nun kommt eine andere Kundengruppe als die für den Shop hinterlegte. Für diese Kundengruppe müssen aber nicht alle Preise hinterlegt werden. Fehlt ein gesonderter Preis für diese Kundengruppe, wird wieder der Preis für die Hauptgruppe genommen. Ich kenne den Code jetzt nicht, müsste ich reingucken. Shopware (auch SW6) ast gerne mit Resourcen rum (die kennen halt nicht mehr Computer mit kb ram). Könnte sein, dass dieser “Fallback” sehr schlecht umgesetzt wurde. Bei Shopware verwendet man gerne JOINS - kann man gar nicht genug haben - und schon hat die Datenbank gut was zu tun Es macht also schon einen Unterschied!
Danke für deine Antwort. Leuchtet ein. Wenn dem so ist, wäre es ziemlich schlecht und wir würden da wahrscheinlich eher weniger an der Performance was ändern können.
Werde aber trotzdem mal die Datenbank auf einen anderen Server schmeißen, vielleicht entlastet es ja ein wenig und man kann noch 'ne Sekunde rauskitzeln.
Insbesondere dann mit Shopware 6 
Nicht wirklich Neu, bin schon ein paar Jahre mit Shopware unterwegs, aber bis jetzt wirklich ohne jegliche bzw. nicht so deutlich frustierende Probleme.
Wobei ich aber zunehmend das Gefühl habe, dass Shopware an diese “unsere” Gruppe der Community nicht mehr sonderlich interessiert ist.
Es macht also schon einen Unterschied!