Martin_Dirlewan
Returning Observer

Content-Projection im Auftrag: Lädt immer alle freigegeben Datensätze bevor Generierung startet

Jump to solution

Hallo,

aktuell befülle ich in einem Auftrag den Generierungstask mit einem Entity einer Datenquelle über den bekannten Weg:

EntityEntry entityEntry = generateTask.createEntityEntry(entityID, pageRefID);

entityStartNodes.add(entityEntry);

Dazu wird mir nun genau dieser eine Eintrag der Content-Projection generiert.

Die Strukturseite der Content-Projection beinhaltet im Daten Reiter keine Filter.

Leider wird jetzt bevor überhaupt die Generierung loslegt im Generierungstask folgende Query ausgeführt:

SELECT t3.FS_ID FROM xxx.TABELLE t3  WHERE t3.FS_RELEASE_TO>1475052555594  AND t3.FS_VALID_FROM<=1475052555594  ORDER BY t3.FS_ID DESC

Danach erst wird der Datensatz anhand der FS_ID geladen und generiert.

Dadurch ist das generieren sehr unperformant, da er über die Query alle freigegeben Datensätze z.b. 125 000 lädt und dann erst diesen einen generiert.

Das eigentliche generieren des einen Datensatzes dauert ca eine Sekunden aber das laden aller Datensätze ca 15 Sekunden.

Vermutlich prüft FirstSpirit inital erst ob der Datensatz anhand der Filter in der Content-Projection vorhanden ist.

Gibt es eine Möglichkeit diese Prüfung zu deaktivieren oder andere Workarounds?

FS Version: 5.1.421.69829

Viele Grüße und Danke vorab

Martin

0 Kudos
1 Solution

Accepted Solutions

Hi Martin,

genau richtig, das wäre ein Feature-Request.

Viele Grüße

Martin

View solution in original post

0 Kudos
10 Replies
Martin_Dirlewan
Returning Observer

Update:

Setzte ich bei der Content-Projection die Maximale Seitenanzahl auf 9000000, würde mir diese immer noch alle Daten generieren aber die Abfrage nach den Datensätze hat sich etwas positiv verändert:

DEBUG 30.09.2016 09:35:37.918 (de.espirit.or.impl.ReleaseSessionHandler): SELECT * FROM (SELECT t3.FS_ID FROM xxx.TABELLE t3  WHERE t3.FS_RELEASE_TO>1475219839130  AND t3.FS_VALID_FROM<=1475219839130  ORDER BY t3.FS_ID DESC) WHERE ROWNUM <= ?

DEBUG 30.09.2016 09:35:37.919 (de.espirit.or.impl.ReleaseSessionHandler): 9000000,

DEBUG 30.09.2016 09:35:38.193 (de.espirit.or.impl.ReleaseSessionHandler): SELECT ... nach dem Datensatz anhand FS_ID

Leider ist das immer noch nicht die perfekte und performanteste Lösung, die Abfrage dauert nun nur noch 300MS aber es werden dennoch alle freigegeben Elemente ausgelesen aber die Logic auf den DB Server verlagert.

Meine Grundfrage würde ich dennoch gerne bestehen lassen.

Gibt es eine Möglichkeit diese Prüfung zu deaktivieren oder andere Workarounds?

0 Kudos

Push Smiley Happy

0 Kudos

Hallo Martin,

wird für die Datenquellen ein externes DBMS verwendet und wenn ja welches? Für Produktiveinsätze ist die interne DerbyDB übrigens nicht empfohlen. Solltest Du diese verwenden, musst Du dich über Performance-Probleme nicht wundern. Die DerbyDB ist nur für lokale Entwicklung gedacht.

Solltest Du eine OracleDB als externes DBMS haben, kann ich Dir aus eigener leidvoller Erfahrung berichten, dass man beim JDBC-Treiber die JDBC-Fetch-Size einstellen muss:

http://makejavafaster.blogspot.de/2015/06/jdbc-fetch-size-performance.html

(Ohne sorgfältige Einstellung des Oracle-JDBC-Treibers ist ist OracleDB oft langsamer als eine MySQL oder Postgres, kommt aber immer auf die individuelle Siaution an).

Außerdem ist FS 5.1 aus der Wartung genommen worden. Aktuell wird nur noch FS 4.2 und FS 5.2 mit Bugfixes versorgt. Die letzte FS 5.1 Version ist 5.1.606 vom August diesen Jahres. EOL war im Juni diesen Jahres. Zukünftige Modulaktualisierungen werden FS 5.1 auch nicht mehr unterstützen müssen. Es wäre ratsam langfristig gesehen bald zu aktualieren.

Grüße Marian

Hallo Marian,

danke für die Info, ja es wird eine Oracle verwendet.

Sobald ich Zeit finde werde ich prüfen ob dies bei FS 5.2 auch auftritt (vermutlich ja).

Die Fetch-Size kann ich gerne noch anpassen, aber das ist nicht das Problem.

Das Problem ist die Query die durch FirstSpirit erzeugt wird diese wird sich ja durch die Fetch-Size nicht verändern ;-).

Die Prüfung ob ein Datensatz in der Contentprojektion enthalten ist würde ich gerne deaktivieren, da diese Abfrage unnötig ist.

Mein Workaround selbst hatte diese Prüfung nur etwas verbessert.

Würde man die Datenbank mit statt 120.000 Datensätzen mit 500.000 befüllen würde das Problem stärker sichtbar, weil ja wie die Query zeigt alle Datensätze geladen werden, die Fetch-Size ist hier ja egal, dann werden alle Datensätze mit der eingestellten Fetch-Size nachgeladen.

Edit: Das mit der Fetch-Size werde ich natürlich auch ausprobieren, aber das Grundproblem dass die Abfrage vorhanden ist wird dadurch nicht gelöst.

Grüße

Martin

0 Kudos

Falls jemand danach sucht in den Datenbanklayern als Config folgendes hinzufügen:

jdbc.property.oracle.jdbc.defaultRowPrefetch=123

0 Kudos

Hallo Martin,

... wobei ich ja bei 120.000 Datensätze die FetchSize auf min 500 oder 1000 setzen würde... und ja, das kostet RAM, aber wenn du den hast und die Daten schneller haben willst? Also meiner Erfahrung nach, wenn alle nötigen Indeces (die mußt Du selber anlegen, unter Umständen legt FS nur einfache an für Primärschlüssel etc und Spaltenkombinationen werden nicht berücksichtigt) angelegt wurden (Stichwort Oracle Query Analyzer), macht die FetchSize schon einen ziemlichen Unterschied.

Siehe auch

https://venkatsadasivam.com/2009/02/01/jdbc-performance-tuning-with-optimal-fetch-size/

http://fasterjava.blogspot.de/2013/04/oracle-jdbc-driver-tuning.html

https://vladmihalcea.com/2015/04/01/resultset-statement-fetching-with-jdbc-and-hibernate/

Grüße Marian

0 Kudos

Hi Marian,

die Indexe hatten wir bereits gesetzt, aber danke für den Hinweis.

Die Fetchsitze mit 123 war lediglich ein Beispiel für die anderen Community Mitglieder damit Sie nicht nach dem Parameter suchen müssen Smiley Happy

Generell aber wäre es schön diese Prüfung für Content Projectionen deaktivieren zu können, dann würde man sich diese Abfrage sparen.

Vermutlich ist dies ein feature Request?

Grüße und Danke

Martin

0 Kudos

Hi Martin,

genau richtig, das wäre ein Feature-Request.

Viele Grüße

Martin

0 Kudos

Hallo Martin,

ist diese Fragestellung noch offen? Benötigst du noch weitere Hilfe oder konnte dir bereits geholfen werden? In diesem Fall wäre es super, wenn diese als "richtige Antwort" entsprechend markierst.

Solltest du inzwischen eine Lösung gefunden haben, wäre es toll, wenn du sie hier bereitstellst.

Viele Grüße,

Sebastian

0 Kudos