Objektrelationales Mapping mit JPA Performance Jonas Bandi Simon Martinelli
“Premature Optimization is the Root of all Evil.” - Donald Knuth “You can't control what you can't measure.” - Tom DeMarco
SQL Logging Logging des JPA-Providers z.B: in persistence.xml: Logging/Profiling Funktionalität der DB Logging/Profiling auf JDBC Ebene Log4jdbc (http://code.google.com/p/log4jdbc/) P6Spy (http://www.p6spy.com/) <property name="eclipselink.logging.level" value="FINE"/>
Minimizing Query Count Typischer Weise entstehen die ersten Persistenz bezogenen Performance Probleme aufgund der Anzahl Queries auf die DB Analyse Optimierung des Globalen Fetch Plans Optimierung des Fetch Plans auf Use-Case Ebene Caching in der Applikation (z.B. DAO, Manager) 2nd Level Cache / Query Cache “Reporting View” mit Constructor Expressions
Teure Queries Analyse, auch auf DB Ebene (Execution-Plan) Meist hilft das setzten eines Index in der DB Optimierung der Fetch-Strategie Optimierung von Queries Verwendung von Hints Verwendung von SQL-Queries
Named Queries Named Queries können vom JPA-Provider beim Deploy oder Startup-Zeitpunkt geparst und kompiliert werden. Das resultierende prepared Statement kann dann wiederverwendet werden.
Instanzierung und Marshalling Result Sets Objekte / Objekt-Graphen Statements In Typischen Anwendungen ist dies kaum ein Performance Problem. Objektinstanzierung ist um Grössenordnungen schneller als DB-Query Bei sehr grossen Datenmengen können Probleme entstehen aufgrund der Session Grösse (Identity- Map)
Constructor Expressions Erlaubt “Views” auf Daten, welche nicht den Entity-Strukturen entspricht.
Session Grösse Eine grosse Session kann zu Performance Problemen führen Out of Memory Garbage Collector Identity Map Typischerweise ein Problem in Batch Szenarien Frühe Erkennung während des Designs sinnvoll Anwendung einer anderen Persistenz Strategie Achtung: Session-Management sollte von Transktions-Steuerung getrennt behandelt werden!
Session Grösse Lösungsansätze Regelmässiges flush() und clear() Bulk-Statements in JPQL Direktes SQL über JDBC Proprietäre Mechanismen des JPA-Providers, z.B. Hibernate Stateless Session
Entity Caching Explizites Caching in der Applikation z.B. DAO, Business-Komponente, Application- Infrastruktur Lifetime kann explizit kontrolliert werden (z.B. Request, Conversation, Session, Application) Verwendung eines transparenten Caching Mechanismus (2nd Level Cache) Lernkurve! Oft beinahe “Black Magic”. Grösse, Invalidation, Transaction-Isolation ...
Query Caching Etliche JPA Providers ermöglichen das Caching von Query-Results. Ist nur in sehr seltenen Fällen sinnvoll Queries sind meist parametrisiert ... Invalidation und Read/Write Verhältnis