Cache - DOAG
Werbung
Erfahrungen mit TopLink in einem Projekt Performance-Aspekte von TopLink Auszug aus einer Diplomarbeit 14. Februar 2017 Erfahrungen mit TopLink in einem Projekt 14. Februar 2017 Die Applikation Südseite: ca. 800.000 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 2 Warum OR-Mapping mit TopLink? 1. Relationale DB ist gesetzt, heißt Oracle 2. Application Server ist ebenfalls gesetzt, heißt WebSphere 3. Zwischen diesen Welten muss vermittelt werden 4. Eigene Mapping-Schicht – in anderen Projekten eingesetzt – ist aufwändig 5. TopLink ist ein OR-Mapper, der am Markt verfügbar ist, wird auch in anderen Projekten eingesetzt. Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 3 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 4 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 5 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. SessionCache 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 10.1.3 wird es einen IsolatedClient-Cache geben, der sehr wahrscheinlich die Lösung für oben genannte Probleme ist. Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 6 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 7 Sequencing (Primärschlüsselvergabe) Toplink empfiehlt den Einsatz einer Sequencing-Tabelle Locks auf dieser Tabelle Besser: Oracle-Sequenzen einsetzen Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 8 Performance-Aspekte von TopLink Auszug aus einer Diplomarbeit 14. Februar 2017 Gliederung Vorstellung der Diplomarbeit Performance-Einstellungen von TopLink Beschreibung des Testablaufs Performance Profiler Ergebnisse Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 10 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 11 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 12 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 13 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 14 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 15 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 16 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 17 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 18 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 Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 19 Ergebnisse Übersicht Indirection Batch Reading Objekte im Cache Lesen über Unit of Work Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 20 Ergebnisse Indirection Ca. 1000 Quell-Objekte und 1000 abhängige Objekte 16000 14000 12000 10000 8000 6000 4000 2000 0 SQL Generation Query Prepare SQL Execute SQL Prepare Cache Row Fetch Object Building ohne Indirection mit Indirection Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 21 Ergebnisse Batch Reading Ca. 8000 Quell-Objekte und 10000 abhängige Objekte Reduzierung der SQLs von 10001 auf 2 70000 60000 SQL Generation Query Prepare SQL Execute SQL Prepare Cache Row Fetch Object Building 50000 40000 30000 20000 10000 0 ohne Batch Reading mit Batch Reading Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 22 Ergebnisse Objekte im Cache 1000 Objekte sollen erzeugt werden Keine SQLs bei Cache-Zugriff 1200 1000 SQL Generation Query Prepare SQL Execute SQL Prepare Cache Row Fetch Object Building 800 600 400 200 0 ohne Cache mit Cache Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 23 Ergebnisse Lesen über Unit of Work Ca. 2500 Objekte werden gelesen 5000 Register SQL Generation Query Prepare SQL Execute SQL Prepare Cache Row Fetch Object Building 4000 3000 2000 1000 0 Session Unit of Work Performance-Aspekte von TopLink Thomas Götz / Stefan Ohlemeyer Seite 24
