Möjligheten att få bättre effektivitet i databasåtkomst från Java. Lennart Henäng, IT-arkitekt, Handelsbanken

Transkript

1 Möjligheten att få bättre effektivitet i databasåtkomst från Java Lennart Henäng, IT-arkitekt, Handelsbanken

2 Agenda Affärskritiska system (en kort bakgrund) Viktiga egenskaper Utmaningar för affärskritiska applikationer skrivna i Java IBM Optim purequery Våra planer

3 Affärskritiska system Vi kör cirka 1000 applikationer i samma operativsystem Upp till flera hundra transaktioner per sekund från IMS, WAS och batch Går något fel så måste problemet hittas och åtgärdas så snabbt som möjligt

4 Viktiga egenskaper för affärskritiska system Högsta möjliga prestanda I förväg fastställda och låsta åtkomstvägar med möjlighet att backa Spårbarhet Användare av revisionsskäl Applikation för problembestämning och snabb problemlösning Säkerhet Behörighet att använda program mot databasen men inte allmän behörighet att läsa och ändra data i databasen

5 Egenskaper hos statisk SQL Statisk SQL ger bättre prestanda Statement caching förbättrar prestanda för dynamisk SQL i verkligheten kan man inte räkna med 100% cache hit Optimering av åtkomstvägar kan ske sällan och vid planerade tillfällen DB2 kan versionshantera åtkomstvägar DB2 kan spara två generationer av åtkomstvägar, för eventuell fallback Beroenden mellan program och objekt registreras i DB2:s katalog En säkerhetsmodell där användare inte behöver åtkomst till data DB2 paketerar åtkomstvägar per program Tydlig identifiering av program som är inblandade i problem Vår vardag sedan 20 år tillbaka

6 Prestandaegenskaper för statisk SQL IBM:s egna tester visar reducerat CPU-uttag för statisk SQL Normalized Throughput by API for JDBC Type 4 Driver 500 % increase/reduction in CPU per transaction compared to JDBC using Type 4 driver Normalized Throughput (ITR) EJB JPA 360 JDBC 420 pq Method Dynamic 446 Client Optimizn Static 485 pq Method Static 524 % increase/reduction in CPU per transn compared to JDBC -50% -35% EJB 2 JPA -14% pq Method Dynamic 6% Client Opt. Static 15% 25% IRWW en OLTP-workload, Type 4 driver Cache hit mellan 70 och 85% 15% - 25% lägre CPU-uttag per transaktion jämfört med dynamisk SQL via JDBC pq Method Static Från artikel i IBM Database Magazine, Issue 2, 2008

7 Hur vi kan följa upp prestanda i våra traditionella system IMS MPP1 Txn1 - Pgm1 - Pgm2 z/os LPAR IMS MPP2 TxnA - PgmX - PgmY DB2PROD IMS MPP3 Txn1 - Pgm1 - Pgm2 DB2 Accounting för IMS-applikationer tillåter oss att se prestandadata ur många perspektiv: Per transaktion (PLAN name) Per modul (package level accounting) Per address space (regionnamn) Per end user ID (IMS thread reuse) App CPU PLAN Txn1 2.1 TN1PLN TxnA 8.3 TNAPLN Detta gör det lätt att isolera prestandaproblem, kapacitetsplanera, analysera programförändringar ur ett prestandaperspektiv, jämföra resursåtgång mellan moduler, etc.

8 Så här fungerar det idag med WebSphere-applikationer A2 A6 Applikationsserver A1 A4 A3 A5 Dataåtkomstlager EJB Query Language Persistenslager JDBC Driver DB2 eller IDS USER1 USER1 USER1 Vad vet DBA:n? - Applikationsserverns IP-adress/started task - WAS connection pooling userid - om applikationen kör JDBC or CLI Vad vet DBA:n inte? - vilken applikation är det som körs? - vilken utvecklare skrev applikationen? - vilka andra SQL-satser kör applikationen? - när ändrades applikationen senast? - hur har CPU-förbrukningen utvecklats? - etc. User CPU PACKAGE USER1 2.1 JDBC USER1 8.3 JDBC USER JDBC

9 Svårigheten att få en helhetsbild av prestanda Applikationsutvecklare Systemkonfiguratör Nätverksadministratör DBA Applikationsserver DB-server JDBC Package JDBC Driver Persistenselager Dataåtkomstlager EJB Query Language WebSphere Connection Pool Affärslogik

10 Vad är det som tar tid i en applikation?

11 Exempel på helhetsbild

12 Databasåtkomst från Java POJO:s med SQL via JDBC eller SQLJ Fördelar Enkelt Kontroll över SQL-satserna Möjlighet till bra prestanda Bra monitorering (om man använder SQLJ) Nackdelar Ingen bra koppling till objektmodellen Tidskrävande för utvecklaren Persistensramverk (ORM) Fördelar Mindre arbete för utvecklaren Åtkomst via OO affärsobjekt Nackdelar Komplexitet Mindre kontroll över SQL-satserna (de genereras) Risk för prestandaproblem och svårt att problembestämma

13 Persistensramverk Spring, Hibernate, ibatis, EJB 3, JPA Isolerar javautvecklaren från databasen Ramverk genererar SQL SQL anropas asynkront mot applikationen uppdateringar sorteras för referensintegritet uppdateringar flyttas till slutet på transaktionen pseudo-sql kan rendera i flera SQL-satser Klassisk problembestämning svår att göra prestandaproblem funktionella problem

14 Alternativa sätt att förbättra situationen Egen kod kan använda JCC Client User API för att föra över viktig korrelationsinformation från javaapplikationen Egen kod kan använda JCC Performance Monitoring API för att samla på sig prestandainformation SQLJ kan användas för att få statisk SQL Native stored procedures kan användas för att få statisk SQL purequery Client Optimization kan användas för att generera statisk SQL Optim Studio och purequery runtime kan ge en komplett miljö för att utveckla och köra affärskritiska applikationer skrivna i Java

15 purequery JDBC JPA API purequery API ibatis Spring SQLJ JPA Runtime purequery Runtime High Speed API JDBC w/purequery IBM Database purequery Metadata, Manageability

16 Data Studio och purequery ger bättre korrelation z/os LPAR Unix or Windows IMS MPP2 TxnA (PLANA) - PgmX - PgmY WAS TxnA (Set Client App=TxnA) - ClassX - ClassY Data Studio och purequery ger samma granularitet för rapportering av WebSphere s DB2-resursåtgång som vi idag har med IMS: Per transaktion (Set Client Application name ) Per class-namn (program - package level accounting) Per address space / IP-adress Per end user ID (DB2 trusted context och DB2 Roles) App CPU TxnA 2.1 TxnB 8.3 Detta gör det lätt att isolera prestandaproblem, kapacitetsplanera, analysera programförändringar ur ett prestandaperspektiv, jämföra resursåtgång mellan moduler, etc.

17 Bättre möjligheter till problembestämning Applikationsutvecklaren För varje databasanrop Genererad SQL-text Åtkomstvägar Beräknad kostnad Beräknad svarstid Körtid och CPU-tid Dataåtkomst (getpages) Trimningsråd Java Profiling purequery DRDA Extentions Databasadministratör För varje SQL-sats Applikationsnamn Java class Java method Java object Radnummer i källkoden Källkodens sammanhang Transaktionsnamn (purequery) Tid för senaste kompilering

18 Vad händer nu? Vi har för avsikt att utreda framtida användning av persistensramverk för vidare utveckling av affärslogik i Java Hibernate JPA I samband med detta kommer vi att titta närmare på purequery pq är ej Open Source pq för med sig licenskostnader hur övertyga utvecklare om att purequery är ett bra sätt att göra åtkomst mot databaser hur väga driftsaspekter (tillgänglighet och prestanda) mot utvecklingsaspekter et cetera

19 Vad förväntar vi oss? purequery ger statisk SQL, med allt vad det innebär hög prestanda stabila åtkomstvägar hög säkerhet dokumenterade objektberoenden ger automatiskt vettig korrelationsinformation ger sammanhängande prestandainformation

20 Frågor?

21 Extramaterial

22 Performance monitor API JDBC-drivern har ett performancemonitor-api Redovisar tiden i respektive lager från applikationen och neråt start(db2systemmonitor.reset_times) start(db2systemmonitor.accumulate_times) stop() getapplicationtimemillis() getcoredrivertimemicros() getnetworkiotimemicros() getservertimemicros() Det vore ännu bättre om performance monitors kunde leverera denna information

23 Korrelation Det är viktigt att det går att korrelera en applikations aktivitet med aktiviteten i databasen I DB2:s JDBC-driver finns ett API för att sända korrelationsinformation till DB2. Fyra metoder på en DB2Connection Deprekerade idag JDBC 4.0 standardmetod

24 Deprekerade metoder DB2Connection.setDB2ClientUser DB2Connection.setDB2ClientWorkstation DB2Connection.setDB2ClientApplicationInformation DB2Connection.setDB2ClientAccountingInformation

25 JDBC 4.0-metod java.sql.connection.setclientinfo Exempel: conn.setclientinfo("clientuser", "Michael L Thompson"); conn.setclientinfo("clientworkstation, "sjwkstn1");

26 Klientinformation DB2 for z/os Vilka är de? DatabaseMetaData.getClientInfoProperties (i JDBC 4.0) Vilka stöds av DB2 för z/os? ClientWorkstation - max 18 tecken ClientUser - max 16 tecken ClientApplicationInformation - max 32 tecken ClientAccountingInformation - max 200 tecken ClientProgramInformation - max 80 tecken

27 Från WAS Under WAS har man endast tillgång till en WSConnection och måste därför använda sig av dess specifika metoder enligt följande exempel WSConnection conn = (WSConnection) ds.getconnection(); Properties props = new properties(); props.setproperty(wsconnection.client_id, "user123"); props.setproperty(wsconnection.client_location, " "); props.setproperty(wsconnection.client_accounting_info, "accounting"); props.setproperty(wsconnection.client_application_name, "appname"); props.setproperty(wsconnection.client_other_info, "cool stuff"); conn.setclientinformation(props); conn.close()