Erfahrungen mit TopLink in einem Projekt Performance-Aspekte von TopLink Auszug aus einer Diplomarbeit 5. Oktober 2016

Erfahrungen mit TopLink in einem Projekt 5. Oktober 2016

Seite 2 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Die Applikation Südseite: ca komplexe Datensätze müssen pro Tag verarbeitet werden. Werden in DB gespeichert Müssen mit vorhandenen Datensätzen verglichen werden Nordseite: Ein abfragendes und zwei aktiv zu versorgendes System mit wenigen hundert Datensätzen pro Tag Sonstiges: Die Daten werden 14 Tage vorgehalten Die Logik ist in Java implementiert, DB ist Oracle Es sollen zwei Websphere Application Server eingesetzt werden

Seite 3 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Warum OR-Mapping mit TopLink?  Relationale DB ist gesetzt, heißt Oracle  Application Server ist ebenfalls gesetzt, heißt WebSphere  Zwischen diesen Welten muss vermittelt werden  Eigene Mapping-Schicht – in anderen Projekten eingesetzt – ist aufwändig  TopLink ist ein OR-Mapper, der am Markt verfügbar ist, wird auch in anderen Projekten eingesetzt.

Seite 4 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Der Cache Hält Objekte vor, so dass nicht alles aus der Datenbank gelesen werden muss Die Suche im Cache erfolgt nach Primärschlüssel. Toplink hält mehrere Caches vor: Session-Cache, Unit-of-Work-Cache. Sorgt für Probleme mit anderen Zugriffen auf die Datenbank, z.B. Stored Procedures Problematisch, wenn mit mehreren Clients über Toplink auf die DB zugegriffen werden soll Cache-Synchronisierung ist eine Lösung, sorgt aber für erhöhten auch unsinnigen Datenverkehr. Nicht immer realisierbar

Seite 5 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Lösch-Job trotz eingeschaltetem Cache Funktioniert! Voraussetzung: Alle Tabelle haben künstliche Primärschlüssel Zusammengesetzte Primärschlüssel nicht benutzen (Beziehungstabellen) Bei natürlichen Primärschlüsseln kommt es zu Problemen, wenn ein gelöschtes Objekt wieder erzeugt werden soll

Seite 6 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Probleme mit dem Caching auf der Südseite Viele Optimistic Locks, wenn auf zwei Servern verteilt, weil zu alte Objekte im Session-Cache gefunden werden Für die Cache-Synchronisierung muss ein IBM-MessageBroker eingesetzt werden, der extrem teuer ist Synchronisierung würde viele überflüssige Daten transferieren Zeiten für die Verarbeitung bei Single-Server-Betrieb: ca. 190ms pro Satz, durch Parallelität im Server verbesserbar. Ein Lösung: Cache-Such-Strategie: Unit-of-Work, Datenbank. Session- Cache nicht vertrauen! Das wird aber nicht angeboten. Erkenntnis: Die Applikation ist bei eingeschaltetem Cache nur auf einer Maschine einsetzbar Hinweis während der Präsentation: In TopLink wird es einen Isolated- Client-Cache geben, der sehr wahrscheinlich die Lösung für oben genannte Probleme ist.

Seite 7 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Probleme ohne Caching auf der Südseite Auch bei der Suche nach Primärschlüssel werden die Daten immer aus der Datenbank geholt Bei einem Schnittstellensatz werden Objekte mehrfach aus der DB gelesen Sogar bei einer Named Query werden wegen des zyklischen Datenmodells einzelne Objekte mehrfach gelesen Massiver Einsatz von Indirections mildert das Problem Zeiten für die Verarbeitung eines Satzes: ca. 500 ms

Seite 8 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Sequencing (Primärschlüsselvergabe) Toplink empfiehlt den Einsatz einer Sequencing-Tabelle Locks auf dieser Tabelle Besser: Oracle-Sequenzen einsetzen

Performance-Aspekte von TopLink Auszug aus einer Diplomarbeit 5. Oktober 2016

Seite 10 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Gliederung Vorstellung der Diplomarbeit Performance-Einstellungen von TopLink Beschreibung des Testablaufs Performance Profiler Ergebnisse

Seite 11 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Vorstellung der Diplomarbeit Thema: Analyse und Bewertung eines objektrelationalen Mapping-Tools für einen Systemintegrator Aufgabe: Analyse von Performance-Einstellungen Auswirkungen der Einstellungen ermitteln Einsatzmöglichkeiten aufzeigen Ziel: Optimierung des Frameworks der Projekte

Seite 12 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance-Einstellungen von TopLink (1/4) Eine Auswahl Performance-Einstellungen haben Auswirkungen auf die Performance von TopLink Zumeist aktivierbar über Mapping-Workbench, teilweise nur über API: Indirection „Just in time“ Loading von abhängigen Objekten Nur die erforderlichen Objekte werden erzeugt Batch Reading Lesen aller abhängigen Objekte auf einmal Verringerung der SQL-Statements Join Reading Lesen aller abhängigen Objekte auf einmal Nur 1:1-Beziehung Join zwischen den in Beziehung stehenden Tabellen Verringerung der SQL-Statements

Seite 13 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance-Einstellungen von TopLink (2/4) Eine Auswahl Named Queries Vordefinierte Abfragen (SQL, EJBQL, Expression) Gespeichert in TopLink-Session unter Namen Verkürzung der Vorbereitungszeit Cache Zwischenspeicherung von Objekten Temporär deaktivierbar Schneller Zugriff auf bestehende Objekte, ohne DB-Zugriff Cursored Streams Abfrageergebnisse können als kleinere Blöcke ausgelesen werden Es werden nicht gleich alle Objekte erzeugt, nur die Benötigten Reduzierung der Zahl erzeugter Objekte

Seite 14 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance-Einstellungen von TopLink (3/4) Eine Auswahl Report Queries Auslesen von einzelnen Datenwerten, keine Objekte Unterstützung der Aggregatfunktionen, z.B. SUM, MAX, COUNT Beschleunigter Datenzugriff Sequencing Vergabe von eindeutigen Identifikatoren für Objekte Vorbelegung von Sequenznummern Verringerung der Datenbankzugriffe Batch Writing Zusammenfassung von mehreren Änderungsabfragen in einem Statement Verringerung der Kommunikation zwischen Anwendung und Datenbank

Seite 15 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance-Einstellungen von TopLink (4/4) Eine Auswahl Parameterized SQL Werte der Übergabeparameter werden erst zur Laufzeit an das Statement gebunden Voraussetzung für Prepared Statement Caching Prepared Statement Caching Zwischenspeichern von JDBC Prepared Statements Verkürzung der Vorbereitungszeiten

Seite 16 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Beschreibung des Testablaufs Performance Test mit Profiling Ausführungsdauer Zeiten in verschiedenen Bereichen zwischen Anwendung und Datenbank Tests in zwei Projekten Untersuchung des Verhaltens unter verschiedenen Voraussetzungen Ergebnisse bestätigen oder widerlegen Erstellen eines Testszenarios für jede Einstellung Zufällige Auswahl von geeigneten Klassen/Tabellen Auswahl/Erstellung von Testfunktionen Testergebnis ist Durchschnitt aus fünf Testdurchläufen

Seite 17 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance Profiler (1/3) Profiling-Tool speziell für TopLink Zeichnet Statistiken für jede einzelne Abfrage auf Folgende Informationen werden aufgezeichnet: Klasse der Abfrage (z.B. ReadAllQuery) Domain-Klasse der abgefragten Objekte Anzahl der Objekte Anzahl der Objekte die pro Sekunde bearbeitet werden Zeit für die Ausgabe von Logging-Informationen

Seite 18 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance Profiler (2/3) Gesamtzeit: −Dauer der gesamten Ausführung der Query Lokalzeit: − Zeit, die auf der Workstation der Users verbracht wird SQL Prepare: −Vorbereitungszeit für das SQL-Statement in Low Level JDBC mit Binden von Parameterwerten SQL Execute: − Ausführungszeit des SQL-Statements auf der Datenbank, vom Senden des SQL bis zum Empfangen des Ergebnisses; Low Level JDBC Row Fetch: − Zeit zum Lesen der Zeilen aus dem Result Set nach Java, hauptsächlich die Zeit von JDBC zum Holen der Daten und Durchführen von Konvertierungen

Seite 19 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Performance Profiler (3/3) Cache: − Zeit für das Durchsuchen und Updaten des Objektcaches, beinhaltet ebenfalls das Anfordern von Locks Object Building: − Zeit für das Erzeugen des Domain-Objekts mit allen Abhängigkeiten Query Prepare: − Zeit zum Vorbereiten der Query vor ihrer Ausführung in TopLink SQL Generation: − Zeit zur Erzeugung des SQL-Statements bevor es zur Datenbank geschickt wird

Seite 20 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Ergebnisse Übersicht Indirection Batch Reading Objekte im Cache Lesen über Unit of Work

Seite 21 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Ergebnisse Indirection Ca Quell-Objekte und 1000 abhängige Objekte

Seite 22 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Ergebnisse Batch Reading Ca Quell-Objekte und abhängige Objekte Reduzierung der SQLs von auf 2

Seite 23 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Ergebnisse Objekte im Cache 1000 Objekte sollen erzeugt werden Keine SQLs bei Cache-Zugriff

Seite 24 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Ergebnisse Lesen über Unit of Work Ca Objekte werden gelesen