Wir setzen im Rahmen unseres Projekts schon sehr lange die Eingabekomp. CMS_INPUT_LIST mit CMS_INCLUDE_CONTENT (wird jedoch derzeit umgestellt zu CMS_INCLUDE_OPTIONS), was an sich nichts Ungewöhnliches sein sollte.
Im Rahmen von Nachforschungsmaßnahmen hinsichtlich allgemeiner "Performance-issues" ist unserem Dienstleister u.a. aufgefallen, dass die o.g. Komponente ein ungewöhnliches "Fetch-All-Verhalten" an den Tag legt, nämlich unabhängig davon wieviele einzelne Werte redaktionsseitig dann ausgewählt wurden, angenommen 10, offenbar weder ein "SELECT ... WHERE ... IN" noch meinetwegen 10 einzelne SELECTs auf die Zieltabelle ausführt (was schon eigentlich für ein schlechtes O/R-Mapping zeugt). In den Logs kann man dann immer sowas sehen wie:
SELECT DISTINCT t15.fs_id FROM p207812_207619.categories_master t15 WHERE t15.fs_valid_to>1341223100087 AND t15.fs_valid_from<=1341223100087
und danach dann :
SELECT t15.categoryname, t15.changed_by, t15.fs_id, t15
.fs_release_to, t15.fs_valid_from, t15.fs_valid_to, t15.prom_fs_id, t15.released_by, t15.wf_col, t15.wf_id FROM p207812_207619.categories_ma
ster t15 WHERE fs_id=? AND t15.fs_valid_to>1341223100088 AND t15.fs_valid_from<=1341223100088
DEBUG 02.07.2012 11:58:21.088 {pID=471181} (de.espirit.or.impl.LocalSessionHandler): 970650,
SELECT t15.categoryname, t15.changed_by, t15.fs_id, t15
.fs_release_to, t15.fs_valid_from, t15.fs_valid_to, t15.prom_fs_id, t15.released_by, t15.wf_col, t15.wf_id FROM p207812_207619.categories_ma
ster t15 WHERE fs_id=? AND t15.fs_valid_to>1341223100091 AND t15.fs_valid_from<=1341223100091
DEBUG 02.07.2012 11:58:21.091 {pID=471181} (de.espirit.or.impl.LocalSessionHandler): 941853,
SELECT t15.categoryname, t15.changed_by, t15.fs_id, t15
.fs_release_to, t15.fs_valid_from, t15.fs_valid_to, t15.prom_fs_id, t15.released_by, t15.wf_col, t15.wf_id FROM p207812_207619.categories_ma
ster t15 WHERE fs_id=? AND t15.fs_valid_to>1341223100091 AND t15.fs_valid_from<=1341223100091
DEBUG 02.07.2012 11:58:21.091 {pID=471181} (de.espirit.or.impl.LocalSessionHandler): 941850,
etc.pp.
D.h. intern werden zunächst (dinstinct) ALLE Ids geholt und dann die Datensätze zu allen.... und dieser Prozess scheint sich auch gerne pro Generierung bzw. Previewanfrage zu wiederholen.
Bei einem sehr umfangreichen Einsatz dieses Mechanismus' kommen in unserem Fall für den Abruf unserer Startseite gerne 20.000+ einzelne SQL-Selects zustande, was keinesfalls das gewünschte Verhalten sein kann und auch Teil des von uns beanstandeten Performance-Lecks darstellen könnte.
Frage: ist dieses Verhalten normal? Hängt es mit unserer relativ alten FS-Version zusammen? In den release-notes findet sich auf Anhieb nichts. Es läuft auch kein Code im Hintergrund und kein eigener Code in irgendwelchen Ausgabekanälen. Zu Testzwecken wurden die Komp. mit kpl. leeren Kanälen nachgebaut und stellen sozusagen nackte Formular ohne Funktionalität dar - die Abfragen geschehen also FS-intern.
FS-Version: 4.2.219.38784
Danke,
Nils Weber
