In den Seiten werden 5 Teaser für die Seitenspalte genutzt.
Da die Seite im Backend extrem langsam ist, habe ich den xdebug-Profiler drüber gejagt: Auf dem Screenshot erkennt man, das 5 mal generateEditCode für den Teaser aufruft (ich habe 5 Teaser in der getestetet Page), darin wird 10x buidlCategorySelect aufgerufen, welches insgesamt 14509 DB-Aufrufe abfeuert.
Das gleiche Spiel wird dann nochmal für das Tab "general und Advanced" im Teaser-Popup gemacht.
Interessant ist, das die zehn buildCategorySelect Abfragen alle identisch sind (also für die Page keine anderen Parameter verwenden):
.SELECT a.idcat AS idcat, b.name AS name, c.level FROM con_cat AS a, con_cat_lang AS b, con_cat_tree AS c WHERE a.idclient = 1 AND b.idlang = 1 AND b.idcat = a.idcat AND c.idcat = a.idcat ORDER BY c.idtree
Würde man die Ergebnismenge also zwischenspeichern, hätte man die Anfrage-Last je Teaser schon mal um das 9 fache minimiert.
Lösungsansatz
Was haltet Ihr von folgendem Lösungsansatz:
Eine suche im Quelltext hat ergeben, das buildCategorySelect lediglich in 3 Komponenten verwendet wird:
- Modul: content_article_incude (input-part des Moduls)
- Modul: article_list_reloaded (input-part des Moduls)
- class.content.type.teaser.php
buildCategorySelect sollte das Ergebnis der Abfrage zwischenspeichern. Z.b. in einem Objekt das nach client-id und lang-id aufgeschlüsselt ist.
Über eine Chain /Hook der beim verändern der Kategorien befeuert wird, müsste dann das Objekt reorganisiert werden. D.h. wenn eine Veränderung der Kategorien von client x in sprache y erfasst wird. müsste dies aus dem Zwischenspeicher-Objekt gelöscht werden.
(Um es alternativ einfacher zu halten, könnte man auch anstatt Änderungen über die Chain zu triggern, einen Timer setzen. So dass z.B. für aktuelle Abfragen der Build nur ein mal ausgeführt wird)
Beim nächsten Aufruf checkt buildCategorySelect ob für den gegebenen Client & Sprache etwas im Zwischenspeicher liegt. Wenn nicht, wird die DB-Abfrage ausgeführt und das Ergebnis wieder neu zwischengespeichert.