Search the FirstSpirit Knowledge Base
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
Hi Martin,
genau richtig, das wäre ein Feature-Request.
Viele Grüße
Martin
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?
Push
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
Falls jemand danach sucht in den Datenbanklayern als Config folgendes hinzufügen:
jdbc.property.oracle.jdbc.defaultRowPrefetch=123
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
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
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
Hi Martin,
genau richtig, das wäre ein Feature-Request.
Viele Grüße
Martin
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