Performance Tuning bei komplexen Domainmodellen
Werbung
Performance Tuning bei komplexen Domainmodellen Christian Dedek Falk Sippach Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: 1.1 www.oio.de [email protected] Java, XML und Open Source seit 1998 ) Projekte ) • Schlüsselfertige Realisierung von Software • Unterstützung laufender Projekte • Pilot- und Migrationsprojekte © 2008 Orientation in Objects GmbH ) Beratung ) ) Akademie ) • Methoden, Standards und • Schulungen, Coaching, Tools für die Entwicklung von offenen, unternehmensweiten Systemen Weiterbildungsberatung, Train & Solve-Programme Performance Tuning bei komplexen Domainmodellen 2 1 Performance? "You need the computing power of a Pentium, 16 MB RAM and 1 GB Harddisk to run Win95. It took the computing power of 3 Commodore 64 (C64) to fly to the Moon. Something is wrong here, and it wasn't the Apollo." Autor unbekannt © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 3 Performance Tuning bei komplexen Domainmodellen 4 Agenda • • • • • • Problemstellung Navigation in Objektnetzen Caching Veränderung von Objektnetzen Diverses Lessons learned © 2008 Orientation in Objects GmbH 2 Hibernate ist ein "einfaches" Persistenzframework <<Tabelle>> Person Collection 1 Person n PERSON_ID<<PK>> FIRSTNAME .... Adresse Adresse Adresse Adresse <<Tabelle>> Adresse session.save(person); ... person = session.load(Person.class, 1L); for (Adresse a : person.getAdressen) { ... } ADRESSE_ID<<PK>> PERSON_ID<<FK>> STRASSE ... Performance Tuning bei komplexen Domainmodellen © 2008 Orientation in Objects GmbH 5 Was ist bei komplexen Domänenmodellen? Entität Beleg Collection Gruppen Positionen G1 G2 Positionen P11 © 2008 Orientation in Objects GmbH P12 Positionen P21 P101 P102 Performance Tuning bei komplexen Domainmodellen 6 3 Performance-Probleme mit Hibernate ? • Hibernate verursacht natürlich Overhead – durch OR-Mapping, Dirty-Checking, DB-Unabhängigkeit, ... • Hibernate bringt auch Vorteile: z. B. Caches – aber ggf. nutzlos durch falsche Verwendung • Was tun? – Optimierungsmöglichkeiten von Hibernate ausnutzen – Stored Procedures oder direkt SQL aus Hibernate aufrufen (DB spezifische Abfrage-Optimierung) – Alternativen zu Hibernate: JDBC, iBatis, ... © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 7 Vorgehensweise Performance-Tuning • Durchführung von Last- und Performanztests • Testszenarien (aus Use Cases) und deren Qualitätsziele festlegen – sinnvolle Testdaten (wenn möglich auch Massendaten für Lasttests) • Problem Testdatenbeschaffung und -reproduktion – Testszenarien sollten mit vertretbarem Aufwand wiederholbar sein – ev. Definition von Key Performance Indikator • Testläufe müssen reproduzierbar sein – vor Performance-Tuning muß das mehrfache Ausführen eines Testlaufs gleiche oder zumindest ähnliche Ergebnisse liefern • Scheduling, Netzwerk... • kleine Performance-Iterationen – ein spezielles Tuning und danach Testlauf um Effekt zu erkennen • Einsatz spezialisierter Werkzeuge © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 8 4 Aktivitäten bei der Testdurchführung Zielbestimmungen und Mengengerüst festlegen Testumgebung und Rahmenbedingungen erfassen Testplan festlegen Maßnahmen durchführen Testszenarien festlegen Test durchführen [gewichtiger Fehler] Analyse durchführen [nicht erfolgreich] [nicht aussagekräftig] [erfolgreich] Misserfolg analysieren [behebbar] [nicht behebbar] © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 9 Lasttesttreiber - The Grinder 3 helloWorldService.py from from from from net.grinder.script.Grinder import grinder net.grinder.script import Test examples.webservices.basic.javaclass import HelloWorld_Impl java.lang import System System.setProperty( "javax.xml.rpc.ServiceFactory", "weblogic.webservice.core.rpc.ServiceFactoryImpl") webService = HelloWorld_Impl("http://localhost:7001/basic_javaclass/HelloWorld?WSDL") port = webService.getHelloWorldPort() portTest = Test(1, "JAXP Port test").wrap(port) class TestRunner: def __call__(self): result = portTest.sayHello(grinder.threadID, grinder.grinderID) grinder.logger.output("Got '%s'" % result) © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 10 5 Lasttestanalysen durchführen logs skript1 data_xxx.log Analyseunterstützung error_xxx.log skript2 Skript Anzahl Instanzen Grinder-Import Speichern als PNG Anzahl Testläufe © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 11 Werkzeuge - Monitoring Tools • Profiler: z. B. JProfiler, JProbe, PerformaSure • JMX-Tooling: z. B. JConsole, AdventNet, MC4J, ... © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 12 6 Hibernate Statistics: JConsole, Statsviewer <bean id="jmxExporter" class="org.springframework.jmx.export.MBeanExporter"> <property name="beans"> <map> <entry key="Hibernate:name=statistics"> <ref local="statisticsBean" /> </entry> </map> </property> </bean> <bean id="statisticsBean" class="org.hibernate.jmx.StatisticsService"> <property name="statisticsEnabled"> <value>true</value> </property> <property name="sessionFactory"><ref bean="sessionFactory"/></property> </bean> © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 13 Werkzeuge - DB-Analyzer • Tracer: z. B. P6Spy, IronTrack SQL, Elvyx • SQL-Clients: z. B. Toad, SQL-Developer (für Oracle DB) © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 14 7 Live-Demo • Anwendung steht für mehrere Minuten • Ermittlung der Ursache per P6Spy und IronTrack SQL – eine bestimmte DB-Abfrage dauert sehr lange • per SQL-Tool (Explain-Plan, Autotrace) <<Tabelle>> Tabelle1 • 1000 Einträge aus Tabelle1 löschen ID <<PK>> .... – "delete from Tabelle1 where ..." – Full Table Scan in Tabelle2 (Constraint-Überprüfung) • Ursache: Index auf TABELLE1_FK-Spalte fehlt <<Tabelle>> Tabelle2 ID <<PK>> TABELLE1_FK <<FK>> ... © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 15 Autotrace-Auswertung in SQL-Tool: Optimierung durch Einführung von DB-Indizes • ohne Index • mit Index © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 16 8 Agenda • • • • • • Problemstellung Navigation in Objektnetzen Caching Veränderung von Objektnetzen Diverses Lessons learned Performance Tuning bei komplexen Domainmodellen © 2008 Orientation in Objects GmbH 17 „Hibernate in 30 Sekunden“ Java Compiler *.class Java Virtual Machine *.hbm.xml Hibernate DB © 2008 Orientation in Objects GmbH hibernate.cfg.xml Performance Tuning bei komplexen Domainmodellen 18 9 Schichtentrennung Business Layer Interceptor UserType SessionFactory Persistence Layer Session Transaction JNDI Configuration Query JDBC JTA Performance Tuning bei komplexen Domainmodellen © 2008 Orientation in Objects GmbH 19 Optimierte Navigation in komplexen Objektnetzen/Relationen ? Mannheim Heidelberg <<Tabelle>> Person GreenSupply PERSON_ID<<PK>> FIRSTNAME .... G7/2 Hauptstrasse 174 id strasse © 2008 Orientation in Objects GmbH position <<Tabelle>> Adresse ID<<PK>><<FK>> STRASSE ... plz Performance Tuning bei komplexen Domainmodellen 20 10 Relationen navigieren • Navigationsgeschwindigkeit optimieren – vollständiges Objektnetz in Speicher laden – komplexe Netze brauchen viel Speicher • Speicherverbrauch optimieren – Relationen werden bei Bedarf nachgeladen – sog. N+1 Problem • mögliche Lösungen – – – – – Batch Fetching Subselect Fetching Join Fetching (Achtung: Karthesisches Produkt) HQL Filter © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 21 N+1 Problem List<Person> allPersons = session.createQuery("from Person").list(); // List<Person> allPersons = session.createCriteria(Person.class).list(); Map<Person, Address> highestAddresss = new HashMap<Person, Address>(); for (Person person : allPersons) { Address highestAddress = null; for (Address address : person.getAddresss() ) { // Initialize the coll. if (highestAddress == null) highestAddress = address; if (address.getPLZ() > highestAddress.getPLZ()) highestAddress = address; } highestAddresses.put(person, highestAddress); } 1 select für Liste der Entitäten + n select für jede navigierte Relation © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 22 11 Batch-Fetching <set name="Addresss" inverse="true" batch-size="10"> <key column="Person_ID"/> <one-to-many class="Address"/> </set> 1 select für Liste der Entitäten select Persons... + n/batchsize selects für jede Gruppe navigierter Relationen select a.* from Address a where a.Person_ID in (?<,?>) © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 23 Laden mit Subselects <set name="Addresss" inverse="true" fetch="subselect"> <key column="Person_ID"/> <one-to-many class="Address"/> </set> 1 select für Liste der Entitäten select Persons... + 1 select für alle navigierte Relationen select a.* from Address a where a.Person_ID in (select p.Person_ID from Person p) © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 24 12 Laden mit joins •Fetchplan <set name="addresses" inverse="true" fetch="join"> <key column="Person_ID"/> <one-to-many class="Address"/> </set> 1 select für Liste der Entitäten mit allen navigierbaren Relationen select p.*, a.* from Person p left outer join Address a on p.Person_ID = a.Person_ID •besonders interessant für n-1-Relation © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 25 Laden mit expliziten Queries Alternative Abfrage für eine Liste der Entitäten mit allen navigierbaren Relationen in spezifischem Anwendungsszenario List<Person> allPersons = session.createQuery("from Person p left join fetch p.Addresss").list(); List<Person> allPersons = session.createCriteria(Person.class) .setFetchMode("addresses", FetchMode.JOIN) .list(); // Iterate through the collections... Es resultiert eine Datenbankanfrage select p.*, a.* from Person p left outer join Address a on p.Person_ID = a.Person_ID © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 26 13 Kartesische Produkte id name Bewoh.. Fla.. id name leistung satz id © 2008 Orientation in Objects GmbH name akti vorname Performance Tuning bei komplexen Domainmodellen 27 Kartesische Produkte • mit jeder Relation potenziert sich die Größe des resultierenden Anfrageergebnisses – DB-Server • Abfragezeit • IO-Aufwand – Applikation • Speicherverbrauch • Mappingaufwand in Hibernate © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 28 14 Filter • Mapping <class name=“City" table=“KA_STADT" lazy="false"> .. <set name=“dezernenten“ table=“KA_DEZERNENT“ cascade="all,delete-orphan" lazy="false"> <key foreign-key="FK_KA_DEZERNENTEN“ column=“KA_STADT_ID" not-null="true" /> <one-to-many class="de.ex.Dezernent" /> <filter name="limitbyParty “ condition=“PARTY_NAME = :partId"/> </set> .. </class> • Anwendung getHibernateTemplate().enableFilter("limitByParty").setParameter(“partId" ,“DIE GRAUEN“);.. getHibernateTemplate().getSessionFactory().getCurrentSession().disableFilter ("limitbyParty"); © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 29 Feintechniken • Value types – Komponente im Kompositum (fehlender Lebenszyklus) • extra Lazy Proxy Collection – ev. nützlich bei sehr großen Assoziationsmengen • Lazy Attribute Fetching – bei LOB-Feldern bereits implizit • Interception statt Proxies – Aufwand eigenimplementierter Lösungen? © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 30 15 Feintuning • zu komplexe DB-Anfragen – DB-spezifische Optimierung der execution plans – Minimierung von join-fetches • zu viele DB-Anfragen – fetch-Typen definieren • eher an der Abfrage als global • Batchsizes an Verarbeitungsgruppen(Screens) orientieren – Alternative - Caching erwägen ? © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 31 Optimierungsstrategie • Ausgangspunkt: Lazy Default-Fetch-Plan – n-1/1-1-Relationen mit lazy=false • dann: Szenarien bezogenes Aufzeichnen • der auslösenden Hibernateanfragen • der resultierenden DB-anfragen • daraus: Optimierung der Zahl und Komplexität der resultierenden DB-Anfragen durch Anpassung der Fetchstrategie der initiierten Hibernateanfragen – spezifische Optimierung einer Anfrage – seltener Optimierung des globalen Fetchplans • Vorsicht Kostenfalle: manuelle Testausführung – globale Fetchplanänderungen erfordern Regressionstest – Lernkurve beachten © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 32 16 bekannte Architektur Muster • Open Session in View Pattern – Navigation nutzt Sessioncache • aber nutzt globale Fetchoptimierung(side Effects ?) – Query wirkt nicht auf Session Cache • Vorteil optimierter spezifischer Fetchplan • spezifische Service Fassade – Ausgangspunkt Navigation über Session – Optimierung über spez. Finder in DAO – DAO-Schnittstelle wird breiter/Wartungsaufwand • generisches DAO (Preload Pattern JavaMagazin 4/08) – schmale Finder-Schnittstelle – keine spezifischer Fetch-Plan © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 33 Performance Tuning bei komplexen Domainmodellen 34 Agenda • • • • • • Problemstellung Navigation in Objektnetzen Caching Veränderung von Objektnetzen Diverses Lessons learned © 2008 Orientation in Objects GmbH 17 Live Demo: Hibernate Statistics © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 35 Caches in Hibernate • First-Level: – – – – immer aktiviert nur solange die eine Session offen ist funktioniert nur bei Aufruf von load/get und bei Assoziationen-Fetch funktioniert nicht bei Queries • Second-Level: – muß erst aktiviert werden – Konfiguration nicht trivial – Query-Cache muß separat aktiviert werden © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 36 18 Cache-Konfiguration • in Hibernate-Settings aktivieren – CacheProvider (EHCache, OSCache, SwarmCache, TreeCache) – use_second_level_cache=true • Cache Regions (angeben für Klassen, Collections oder Queries) – Usecase spezifisch optimieren – usage: Caching Strategie • • • • read-only:beste Performance nonstrict-read-write: nur für nicht konkurrierende Zugriffe read-write: gewährleistet read-commited transactional: nur bei JTA-Umgebungen © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 37 Gefahren bei Second Level Caches • andere Applikationen, welche die DB ändern – Cache muß regelmäßig validiert werden • zu viele schreibende Zugriffe – Cache-Miss größer als Cache-Hit: schlechtes Cache-Ratio • zu kleine Dimensionierung des Cache – sollte aber auch nicht zu groß dimensioniert werden (GC dauert länger, längere Validierungsphase mit DB) Performance kann sogar sinken (durch hohen Verwaltungsaufwand). © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 38 19 Problem: fehlender Cache-Hit • Beobachtung: Session Cache arbeitet nicht richtig – immer wieder die gleichen SQL-Selects im Log-Output • Ursache: statt mit load/get wird mit HQL-Findern gearbeitet – von AndroMDA generierter Code arbeitet mit findById – Bug mittlerweile gefixed: AndroMDA generiert jetzt session.get() • Alternative für finder: Query-Cache einschalten © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 39 Query-Cache • Query-Cache überhaupt erstmal einschalten <prop key="hibernate.cache.use_query_cache">true</prop> • Query-Cache speichert nur IDs – muß mit Entity-Cache zusammen arbeiten • nur sinnvoll für häufige Abfragen mit immer gleichen Parametern • darum werden Queries defaultmäßig nicht gecached – setCacheable(true) aufrufen! public Object getObjectByName(String name) { Query q = session.createQuery("from Object where name = ?"); q.setParameter(0, name); q.setCacheable(true); return q.uniqueResult(); } © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 40 20 Unwirksamer Cache • z. B. bei Abfragen mit ständig wechselnden Parametern hql = "from de.oio.Firma ... where validFrom <= :date and validTo >= :date"; Query q = session.createQuery(hql); for(..) { q.setDate(..); q.list(); } • ggf. eigene Caches implementieren – insbesondere wenn immer der gleiche Datensatz geholt wird – dazu alle abzufragenden Datensätze laden und in Java vergleichen • funktioniert nur bei überschaubarer Anzahl von Datensätzen! © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 41 Performance Tuning bei komplexen Domainmodellen 42 Agenda • • • • • • Problemstellung Navigation in Objektnetzen Caching Veränderung von Objektnetzen Diverses Lessons learned © 2008 Orientation in Objects GmbH 21 Collections • Arten – Indizierte collections • maps/lists/arrays über eine index Spalte – Sets • Uniqueness – Bags • keine Garantien zu Reihenfolge oder Uniqueness • Id-bag © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 43 Performance Tuning bei komplexen Domainmodellen 44 Flushing-Probleme: Vorher © 2008 Orientation in Objects GmbH 22 Hintergrund • Hibernate Session: – 1st Level Cache, muß mit DB synchronisiert werden -> Flushing • Flushing: – Session.flush() – Transaction.commit() – bei DB-Abfragen (Dirty Check) • Dirty Check: – Objektänderungen so lange wie möglich in der Session vorgehalten – bei Abfragen ggf. zuerst aufgelaufene Änderungen wegschreiben – Änderungen werden ermittelt und DML-Anweisungen generiert © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 45 Probleme • je mehr Daten in der Session, desto länger dauert Dirty Check • Flush aber oftmals gar nicht notwendig • Lösungen: – – – – Operationen neu ordnen Objekte aus Session abhängen (read-only) mit dem Flush warten bis zum Commit (write behind) Anwendung kontrolliert explizit Flushing • Default Flushing Verhalten ändern: – MANUAL, COMMIT, AUTO, ALWAYS © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 46 23 Nachher: Flushmode.COMMIT © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 47 Massendaten-Verarbeitung: 1000 Datensätze löschen for (...) { Entity e = session.load(Entity.class, id); session.delete(e); } 2000 SQL-Anweisungen Session-Cache wird unnütz befüllt eine SQL-Anweisung minimale DB-Kommunikation String hql = "delete from Entity where id between ..."; session.createQuery(hql).execute(); © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 48 24 Single SQL statement • Objekte können verarbeitet werden, ohne sie vorher in Speicher zu laden (Hibernate unterstützt INSERT/UPDATE/DELETE) – update Person set gehalt = :newGehalt where status = 'Chef' • separates Löschen von vielen Elementen ist ineffizient – session.delete() – Vorsicht: Springs HibernateTemplate.deleteAll(Collection col) iteriert über Collection und löscht jedes Element einzeln • Collection-Mapping Delete-Optimierung – Hibernate erzeugt einzelnes DELETE bei Collection.clear() – funktioniert nicht mit inverse="true" (bidirektionalen Beziehungen) © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 49 Stateless Session sessionFactory.openStatelessSession() • ideal für Ausführung von Bulk/Batch Operationen (funktioniert auch mit detached Objects) • ähnlich einer normalen Session, aber – – – – kein Persistenz-Kontext, kein Cache (weder 1st noch 2nd) kein automatisches Dirty Checking oder transaktionales Write Behind kein kaskadierendes Verhalten, ignoriert Collections umgeht Event-Modell und Interceptoren © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 50 25 DB Performance Tuning • DB Administratoren fragen • SQL-Dialect nach herstellerspezifische Features untersuchen – ggf. eigenen Dialekt schreiben • DB-Indizes – – – – fehlen meist bei Grüne-Wiesen-Projekten DB generiert typischerweise nur Unique-Constraints (PK, ...) FK-Felder sollten Index erhalten, wenn Sie oft abgefragt werden aber: • nicht zu viele Indizes sonst leidet Insert/Update Performance • Indizes immer überprüfen, ob sie überhaupt verwendet werden © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 51 Hibernate Indizes • Hibernate unterstützt Index-Definition in Mapping-Files • für Properties und Assoziationsenden <property name=".." index="idx" /> <many-to-one name=".." index="fk_idx" /> © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 52 26 Agenda • • • • • • Problemstellung Navigation in Objektnetzen Caching Veränderung von Objektnetzen Diverses Lessons learned © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 53 Probleme bei Rich-Client Architekturen • leider oft: feingranulare Services – CRUD-Schnittstelle für jede Domain-Klasse (auch für jedes Kind) – viele Aufrufe an Backend (Netzwerkverkehr) • bei Objektnetzen hängt teilweise der ganze Objektbaum dran – Speicherprobleme bei falschem oder fehlendem Umhängen der Abhängigkeiten (besonders bei bidirektionalen Verbindungen) • besser: grobgranulare Fassaden – Usecase-spezifisch – Minimierung der Aufrufe ans Backend – Verringerung der Memory-Spitzen durch weniger RMI-Kopien © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 54 27 C2 wird ans Backend geschickt und dann in Collection Children ausgetauscht vorher: Parent C1 C2 nachher: service.method(C2) Children IN OUT Parent Parent_1 Children Children_1 C1 C1_1 C2 © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 55 Herausgelöste Objekt-Teilgraphen • Speicher läuft voll bei Remote-Kommunikation – durch RMI erhalten wir mehrere Objekte im Speicher mit gleicher Datenbank-Identität – diese "Kopien" enthalten ggf. wieder den kompletten (kopierten) Objektgraphen, je nach globaler Fetching-Strategie • GC kann Speicher nicht freiräumen, wenn noch Referenzen auf Kopien des Objektgraphen bestehen – z. B. durch falsches Setzen der bidirektionale Beziehungen – Workaround für bidirektionale Beziehungen: addChild(Child child) { this.getChildren().add(child); child.setParent(this); } © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 56 28 Probleme Hibernate Interceptor public interface Interceptor { public boolean onLoad(..) throws CallbackException; public boolean onFlushDirty(..) throws CallbackException; boolean onSave(..) throws CallbackException; public void onDelete(..) throws CallbackException; [..] public void postFlush(Iterator entities) throws Callba..; public void afterTransactionCompletion(Transaction tx); Aufräumen des Interceptor: afterTransactionCompletion() Aber: Aufruf nur bei Hibernate-Transaktionen, nicht bei JTA © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 57 ThreadLocal bei Hibernate Interceptor • ThreadLocal-Variable muß immer aufgeräumt werden – ThreadLocal.remove(); – ThreadLocal kann sonst Memory-Leaks verursachen • Verwendung eines ThreadLocals im Hibernate Interceptor – bei Nicht-Hibernate-Transaktionen wird nicht aufgeräumt – ThreadLocal-Objekt bleibt also bei einer Exception im Speicher – gefixed ab Hibernate 3.2.6: • es wird nun immer implizit eine Hibernate-Transaktion gestartet • dadurch wird Interceptor korrekt deinitialisiert • Spring-Workaround für ältere Hibernate-Versionen: – AOP-Throw-Advice für Service-Aufrufe, der Interceptor aufräumt © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 58 29 Probleme Threadlocal • Vergleiche – http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html – http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html • Der kleine Unterschied: – public void remove() • Removes the value for this ThreadLocal © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 59 Garbage Collector Aufwand optimieren • Genutzten Speicher minimieren – Speicher ist zwar immer billiger aber weiterhin begrenzt • z.B. ineffizientes caching führt zu erhöhtem Bedarf an Garbage Collections – Caching ist kein High-level-Fix für Probleme tieferer Schichte – explizite Eviction an der SessionFactory als manueller Eingriffspunkt im API • Bessere GC-algorithmen – hilft bei „typischen Verfügbarkeitsproblemen“ • Phänomen seit Jahrzehnten bei GC-Sprachen bekannt – paralleler GC-algorithmus auf multi-prozessor systemen – schwierig (aber notwendig) zu testen © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 60 30 Spring Bugs • http://jira.springframework.org/browse/SPR-1690 – falsche Errorcodes für Deadlocks in DB • http://jira.springframework.org/browse/SPR-2888 – Deadlock bei spezieller init – Deadlock beim Exceptionhandling von Connections • http://jira.springframework.org/browse/SPR-3961 – Running benchmarks under high loads with 8 or more concurrents threads I see significant lock contention from the synchronized block in org.springframework.aop.framework.AdvisedSupport.getInterceptorsA ndDynamicInterceptionAdvice. This is a significant bottleneck in our benchmarks. • http://jira.springframework.org/browse/SPR-1968 – wzeite readonly Session in Spring um JSF zu unterstützen © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 61 Hibernate Bugs • http://opensource.atlassian.com/projects/hibernate/browse/HHH2841 Deadlock im Jboss offen • http://opensource.atlassian.com/projects/hibernate/browse/HHH1669 mögliches Memoryleak • http://opensource.atlassian.com/projects/hibernate/browse/HB1246 seltener Deadlock wont fix • Deadlocks in Treibern – http://opensource.atlassian.com/projects/hibernate/browse/HHH-1167 • Deadlocks in Pools – http://opensource.atlassian.com/projects/hibernate/browse/HHH-3189 © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 62 31 Agenda • • • • • • Problemstellung Navigation in Objektnetzen Caching Veränderung von Objektnetzen Diverses Lessons learned © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 63 Best Practices I • Anwendung einer optimistic concurrency zur Implementierung einer hohen Skalierbarkeit sinnvoll • Definition einer klaren Sessionmanagement Strategy – vorteilhaft ist Einbindung in gut dokumentierte Patterns • Default Fetch Plan für Assoziationen ist lazy – Optimierung erfolgt gemäß Kapitel 2 – sehr breiter Featureset(Filter,Projektionen,Interceptoren..) zur Optimierung © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 64 32 Best Practices II • Definition der Caching Strategie – Festlegen welche Bereiche über Navigation (Session Cache) und welche über Finder (Query Cache optimieren) – Entity-Cache fein anpassen und tunen • Verständnis für Implementierungsdetails hilft beim Optimieren • Definition einer einheitlichen flush-Strategie – Feintuning: Hibernate auto-flush vs. use case spezifische Synchronisation • Untersuchung der GC-Aktivitäten – Minimierung des GC-Aufwands – Erkennung (minimaler) Memoryleaks © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 65 Nichtfunktionale QM-Strategie • Performance Meta Antipattern „Performance Afterthoughts“ ist Realität in der agilen Entwicklung • nichtfunktionales Qualitätsmanagement benötigt – – – – fachlich richtige und realitätsnahe Testfälle Automatisierung Entwicklungsbegleitung Technologische Kompetenz • Hibernate/Spring • eingesetztes RDBMS – Integration ins Entwicklungsteam • Empfehlung: Definition von Key Performance Indikatoren © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 66 33 Architekturelle Reife • Die vorkonfektionierte Grobarchitektur Spring/Hibernate – hat viele gute Standardeinstellungen in Bezug auf Performanzaspekte • in beiden Frameworks – Communities sorgen für Praxisnähe und -einsatz der Ideen – bietet bei Bedarf sehr viele Möglichkeiten für Performanzoptimierungen • oft einfach durch reine Konfiguration • Leistungsgrenzen der Kombination Spring/Hibernate sind am technologischen Gesamtstack aus JVM/OS/RDBMS/Netzwerk/IO angelehnt © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 67 Der Kaufmann rechnet - oder Reife vs. Produktivität • POJO-Development erhöht Entwicklungsgeschwindigkeit und senkt den technischen QM-Aufwand – fast direkte Implementierung fachlicher Modelle möglich • rasante Entwicklung von Spring/Hibernate/Tooling seit 2003 senkte bisher die Entwicklungsgeschwindigkeit – sehr hoher Entwicklungsdruck fordert Qualitätsopfer • Vorteil: Open Source schafft hier Transparenz – erfordert ständigen KnowHow-Transfer in die Entwicklung • gerechtfertigt durch Produktivitäts- und Qualitätssteigerungen – zwingt zu Migrationen der Infrastruktur • Bsp. MDD-Generatoren, Konfigurations-, Buildmanagement, Codeanalysewerkzeuge © 2008 Orientation in Objects GmbH Performance Tuning bei komplexen Domainmodellen 68 34 ? ? ? ? ? Fragen ? Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: 1.1 www.oio.de [email protected] Vielen Dank für Ihre Aufmerksamkeit ! Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: 1.1 www.oio.de [email protected] 35
