Hallo zusammen,
meine Anfrage richtet sich vor allen an größere Shops, die viele Artikel (über 100T) und viele User gleichzeitig im Shop haben (50-100).
Wir haben einen JTL Shop 4.06 gehostet auf einem ALL-Inkl. XXXL Server mit folgender Ausstattung:
2x Intel® Xeon® E5-2630v4
2x10 Prozessorkerne 2,2GHz Hyper-Threading
64 GB Reg ECC RAM
4 TB SATA (RAID 10)
+ 2x 250 GB SSD (RAID 1)
Die Datenbank liegt auf der SSD und wir nutzen Redis als Cache System.
Jetzt zum Problem:
Startet man ein Plugin Update oder ändert verschiedenste Einstellungen im Backend, so invalidiert sich der komplette Cache.
Wir gehen davon aus, dass zum Zeitpunkt des Invalidierens um die 50 Leute auf der Seite aktiv sind.
1. Problem Kategoriebaum
Der Kategoriebaum muss einmal neu in den Cache geschrieben werden. Grundsätzlich eine Abfrage, die nur 5 Sekunden dauert. Dadurch, dass aber 50 Leute gleichzeitig auf der Seite sind, wird dieser SQL jedes Mal neu aufgerufen. Kommen weiter User hinzu, so werden weitere SQL's aufgerufen, um die Abfrage einmal fertig zu schreiben.
Bei uns ist es dann nicht unüblich, dass dieser eine kurze SQL über 10 Minuten läuft und davon dann bis zu 150 Stück. Den Shop 10 Minuten down zu haben wäre ja noch ok, aber kommen wir zum nächsten Problem was noch viel gravierender ist.
2. Problem Artikel
Da auch alle Artikelobjekte neu geschrieben werden müssen kommen neben den obigen Abfragen noch massenhaft Abfragen dieser Art auf dem SQL-Server an:
Diese Abfragen dauern pro Artikel jeweils 10-20 Sekunden. Nach wenigen Sekunden stauen sich am SQL-Server über 100 Slow-Queries an, die exponentiell ansteigen bis man Ladezeiten im Shop von bis zu 60 Sekunden hat.
Erst wenn der Cache auf ca. 4-5GB angestiegen ist - was locker 4-5 Stunden dauern kann - erholt sich der SQL-Server wieder.
Was muss sich ändern?
1. Im Backend muss sich vor Änderung jeder Einstellung ein Hinweisfeld öffnen, das daraufhin weist, dass der Cache sich invalidieren würde.
2. Der SQL zum Aufbau des Kategoriebaumobjekts darf nur ein einziges mal abgesetzt werden.
Ich weiß allerdings nicht, was man gegen das Problem mit dem Artikelcache tun kann - ich merke langsam nur, dass man als größerer Shop mit dem aktuellen JTL Shop System an seine Grenzen stößt.
Wir sind schon seit mehr als einem Jahr in Diskussion mit JTL, aber so richtig was ändern, tut sich nicht.
Vielleicht gibt es ja noch andere mit diesem Problem, die auch schon eine Lösung parat haben.
meine Anfrage richtet sich vor allen an größere Shops, die viele Artikel (über 100T) und viele User gleichzeitig im Shop haben (50-100).
Wir haben einen JTL Shop 4.06 gehostet auf einem ALL-Inkl. XXXL Server mit folgender Ausstattung:
2x Intel® Xeon® E5-2630v4
2x10 Prozessorkerne 2,2GHz Hyper-Threading
64 GB Reg ECC RAM
4 TB SATA (RAID 10)
+ 2x 250 GB SSD (RAID 1)
Die Datenbank liegt auf der SSD und wir nutzen Redis als Cache System.
Jetzt zum Problem:
Startet man ein Plugin Update oder ändert verschiedenste Einstellungen im Backend, so invalidiert sich der komplette Cache.
Wir gehen davon aus, dass zum Zeitpunkt des Invalidierens um die 50 Leute auf der Seite aktiv sind.
1. Problem Kategoriebaum
Der Kategoriebaum muss einmal neu in den Cache geschrieben werden. Grundsätzlich eine Abfrage, die nur 5 Sekunden dauert. Dadurch, dass aber 50 Leute gleichzeitig auf der Seite sind, wird dieser SQL jedes Mal neu aufgerufen. Kommen weiter User hinzu, so werden weitere SQL's aufgerufen, um die Abfrage einmal fertig zu schreiben.
Bei uns ist es dann nicht unüblich, dass dieser eine kurze SQL über 10 Minuten läuft und davon dann bis zu 150 Stück. Den Shop 10 Minuten down zu haben wäre ja noch ok, aber kommen wir zum nächsten Problem was noch viel gravierender ist.
2. Problem Artikel
Da auch alle Artikelobjekte neu geschrieben werden müssen kommen neben den obigen Abfragen noch massenhaft Abfragen dieser Art auf dem SQL-Server an:
SQL:
SELECT
tartikel.kArtikel AS tartikel_kArtikel,
tartikel.fLagerbestand AS tartikel_fLagerbestand,
tartikel.cLagerBeachten,
tartikel.cLagerKleinerNull,
tartikel.cLagerVariation,
teigenschaftkombiwert.kEigenschaft,
tartikel.fVPEWert,
teigenschaftkombiwert.kEigenschaftKombi,
teigenschaft.kArtikel,
teigenschaftkombiwert.kEigenschaftWert,
teigenschaft.cName,
teigenschaft.cWaehlbar,
teigenschaft.cTyp,
teigenschaft.nSort,
teigenschaftwert.cName AS cName_teigenschaftwert,
teigenschaftwert.fAufpreisNetto,
teigenschaftwert.fGewichtDiff,
teigenschaftwert.cArtNr,
teigenschaftwert.nSort AS teigenschaftwert_nSort,
teigenschaftwert.fLagerbestand,
teigenschaftwert.fPackeinheit,
teigenschaftwertpict.cType,
teigenschaftwertpict.kEigenschaftWertPict,
teigenschaftwertpict.cPfad,
teigenschaftwertaufpreis.fAufpreisNetto AS fAufpreisNetto_teigenschaftwertaufpreis,
COALESCE(ek.score, 0) nMatched
FROM
tartikel
JOIN teigenschaftkombiwert ON tartikel.kEigenschaftKombi = teigenschaftkombiwert.kEigenschaftKombi
LEFT JOIN teigenschaft ON teigenschaft.kEigenschaft = teigenschaftkombiwert.kEigenschaft
LEFT JOIN teigenschaftwert ON teigenschaftwert.kEigenschaftWert = teigenschaftkombiwert.kEigenschaftWert
LEFT JOIN(
SELECT teigenschaftkombiwert.kEigenschaftKombi,
COUNT(
teigenschaftkombiwert.kEigenschaftWert
) AS score
FROM
teigenschaftkombiwert
INNER JOIN tartikel ON tartikel.kEigenschaftKombi = teigenschaftkombiwert.kEigenschaftKombi
LEFT JOIN tartikelsichtbarkeit ON tartikelsichtbarkeit.kArtikel = tartikel.kArtikel AND tartikelsichtbarkeit.kKundengruppe = 1
WHERE
kEigenschaftWert IN(
SELECT
kEigenschaftWert
FROM
teigenschaftkombiwert
WHERE
kEigenschaftKombi = 341625
) AND tartikelsichtbarkeit.kArtikel IS NULL
GROUP BY
teigenschaftkombiwert.kEigenschaftKombi
) ek
ON
ek.kEigenschaftKombi = teigenschaftkombiwert.kEigenschaftKombi
LEFT JOIN teigenschaftsichtbarkeit ON teigenschaftsichtbarkeit.kEigenschaft = teigenschaftkombiwert.kEigenschaft AND teigenschaftsichtbarkeit.kKundengruppe = 1
LEFT JOIN teigenschaftwertsichtbarkeit ON teigenschaftwertsichtbarkeit.kEigenschaftWert = teigenschaftkombiwert.kEigenschaftWert AND teigenschaftwertsichtbarkeit.kKundengruppe = 1
LEFT JOIN teigenschaftwertpict ON teigenschaftwertpict.kEigenschaftWert = teigenschaftkombiwert.kEigenschaftWert
LEFT JOIN teigenschaftwertaufpreis ON teigenschaftwertaufpreis.kEigenschaftWert = teigenschaftkombiwert.kEigenschaftWert AND teigenschaftwertaufpreis.kKundengruppe = 1
WHERE
tartikel.kVaterArtikel = 196772 AND teigenschaftsichtbarkeit.kEigenschaft IS NULL AND teigenschaftwertsichtbarkeit.kEigenschaftWert IS NULL AND(
teigenschaftkombiwert.kEigenschaftWert,
COALESCE(ek.score, 0)
) IN(
(110241, 1),
(110242, 1),
(110243, 1),
(110244, 1),
(110245, 1),
(110246, 1),
(110247, 1),
(110248, 1),
(110249, 1),
(110250, 1),
(110251, 1),
(110252, 1),
(110253, 2),
(110254, 1),
(110255, 1),
(110256, 1),
(110257, 1),
(110258, 1),
(110259, 2),
(110260, 1),
(110261, 1),
(110262, 1)
)
GROUP BY
teigenschaftkombiwert.kEigenschaftWert
ORDER BY
teigenschaft.nSort,
teigenschaft.cName,
teigenschaftwert.nSort
Diese Abfragen dauern pro Artikel jeweils 10-20 Sekunden. Nach wenigen Sekunden stauen sich am SQL-Server über 100 Slow-Queries an, die exponentiell ansteigen bis man Ladezeiten im Shop von bis zu 60 Sekunden hat.
Erst wenn der Cache auf ca. 4-5GB angestiegen ist - was locker 4-5 Stunden dauern kann - erholt sich der SQL-Server wieder.
Was muss sich ändern?
1. Im Backend muss sich vor Änderung jeder Einstellung ein Hinweisfeld öffnen, das daraufhin weist, dass der Cache sich invalidieren würde.
2. Der SQL zum Aufbau des Kategoriebaumobjekts darf nur ein einziges mal abgesetzt werden.
Ich weiß allerdings nicht, was man gegen das Problem mit dem Artikelcache tun kann - ich merke langsam nur, dass man als größerer Shop mit dem aktuellen JTL Shop System an seine Grenzen stößt.
Wir sind schon seit mehr als einem Jahr in Diskussion mit JTL, aber so richtig was ändern, tut sich nicht.
Vielleicht gibt es ja noch andere mit diesem Problem, die auch schon eine Lösung parat haben.
Zuletzt bearbeitet: