Websphere Performance Tuning - Mirko Novakovic Hamburg, 19. 9. 2006
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Websphere Performance Tuning
Mirko Novakovic
novakovic@codecentric.de
Hamburg, 19. 9. 2006Agenda Performance Tuning Grundlagen Analyse und Tools Tuning Best Practises
Performance - Werte und Maßeinheiten Die Performance ist ein Maß für das Zeitverhalten eines Softwaresystems Performance ist definiert durch die Indikatoren Antwortzeit (response time) und Durchsatz (throughput) Bei Java SE Systemen ist die Antwortzeit der Kernindikator für die Performance – bei Java EE Systemen kann der Durchsatz entscheidend sein. Antwortzeit und Durchsatz können gegensätzliche Anforderungen sein.
Performance - Antwortzeit Die Antwortzeit ist die gemessen Zeit zwischen Absenden der Anfrage (request) und vollständigen Empfang der Antwort (response) Die Antwortzeit wird in Sekunden oder Millisekunden gemessen Die Antwortzeit bei Java EE Anwendungen ist die End-to-End Antwortzeit, die der Benutzer erfährt (t) Der Percentile Graph gibt die prozentuale Verteilung der Antwortzeiten an
Performance - Durchsatz Der Durchsatz ist definiert durch die Anzahl von Anfragen (requests), die ein System pro Zeiteinheit verarbeiten kann Bei webbasierten Systemen wird der Durchsatz den Einheiten Pageimpressions pro Sekunde oder Requests pro Sekunde gemessen Eine weitere Einheit kann die Anzahl der Transaktionen oder Datenbankabfragen pro Sekunde sein – insbesondere bei „Batch“ Systemen
Zusammenhang – Antwortzeit und Durchsatz Antwortzeit gegen Durchsatz Antwortzeit gegen Anzahl Benutzer
Tuning Bereiche Java SE und Java EE
View Technologien
– Swing, AWT, Applet, WebStart
– JSP, JSTL, Taglibs
– XML, XSL, FOP
Web Frameworks (Struts, JSF, WebWork)
Business Logik
– EJB (Session, Entity, MessageDriven)
– Leightweight Container (Spring, Picocontainer,
Avalon)
– OR Mapper (Hibernate, TopLink)
– POJOS
Backend Connections
– JDBC
– JMS
– J2CBeteiligte Systeme bei Java SE und Java EE
Webserver (Apache, IIS, iPlanet)
Applikationsserver (WebSphere, Weblogic, JBoss)
Datenbanken (Oracle, DB2, MySQL)
Legacy Systeme (IMS, CICS, SAP, Siebel)
Externe Komponenten
– Netzwerkkomponenten (Router, Switches, Firewalls, Latency)
– Maschinen Resourcen (CPU, IO, Memory)Komplexität führt zu Kommunikationsproblematik
Lösung: Application Performance Management
High Level - System Sicht
24x7 Monitoring der Java Anwendung und
Infrastruktur
Detect
Betrieb
Frühzeitige Erkennung von Performance und
Stabilitäts Problemen
Problembereich eingrenzen können
SLA Reporting
Diagnose
Diagnostizieren des Problems unter realen
Bedingungen
Geringer Overhead für Diagnose unter Last
Test
JVM Übergreifende Metriken (AppServer, etc.)
Eingrenzung des Problems auf Klassen oder
Komponentenebene
Entwicklung
Resolve
Beheben des Performance oder Stabilitäts
Problems
Profiling und Analyse des Problems bis auf
Zeilen- bzw. Codeebene
Finden von Memoryleaks oder Ressource
Detail - Source Code Sicht ProblemenDiagnose und Profiling Informationen
Performance Informationen der Anwendung – Blackbox Sicht
– Antwortzeitverhalten,…
Performance Informationen der Anwendung – Whitebox Sicht
– Methoden Durchlaufzeiten, Heap Snapshot, Objekterzeugungen,…
Applikationsserver Statistiken
– Connection Pool, Thread Pool, EJB Statistiken, Servlet Statistiken,…
JVM Statistiken
– Heap Statistiken, GC Informationen,…
System Informationen
– CPU, Memory, IO, Netzwerk,…
Datenbank/Legacy Informationen
– Indizes, Caching, Zugriffoptimierungen, IMS Queues,…Statistik: Performance Probleme von Java Anwendungen 1. Memory Leaks 2. Datenbank Anbindung 3. Garbage Collection … Ineffektiver Code Netzwerk Problem
Analyse und Tools
Performance Tuning Prozess (1) 1. Anforderungen an Performance und Verfügbarkeit definieren 2. Performance und Verfügbarkeit messen (Benchmarking) 3. Messung analysieren 4. Tuningmaßnahmen und Hypothesen aufstellen und priorisieren 5. Maßnahme mit höchster Priorität umsetzen 6. Schritt 2-5 wiederholen bis Anforderungen erfüllt
Performance Tuning Prozess (2)
Benchmark etablieren
– Identifikation fachlicher Anwendungsfälle
• Basis für die Verskriptung der Lasttests und das Profiling
• Realistische Szenarien in Abstimmung mit der Fachabteilung
– Identifikation kritischer Schnittstellen
• Legacy Systeme
• DB Zugriffe
• Externe/Interne WebServices
Optimal: Automatisierung (Ant, CruiseControl, Maven, etc.)Lasttest Tools – JMeter (1)
100% Java Lasttesttool von Apache
– Sampler nicht nur für http -> Perl Skripte, RMI, IIOP,
Datenbank Queries, SOAP, FTP,…
OpenSource
– Einfache Erweiterung für spezielle Umgebungen
Ant Tasks für Steuerung und Reporting
Alternativen: Mercury Loadrunner, Segue
SilkPerformer, Grinder 3Lasttest Tools – JMeter (2)
Entwickelt Lasttest mit JMeter
(Grafische Oberfläche)
Erzeugt
Test-SkriptLasttest Tools – JMeter (3) Die Darstellung der Auswertung erfolgt grafisch oder in Tabellenform
Problemfelder Memory Leaks – OutOfMemoryError – Anwendungsfehler durch Loitering Objects – Hoher Speicherbedarf der Anwendung – Fragmentierung des Heaps durch pinned Objects Cycling Objects/Garbage Collection – Anwendung erzeugt viele kurzlebige Objekte – Einstellungen der JVM Performance Engpässe – Ineffektiver Code oder Nutzung von APIs – Datenbankzugriffe
Commandline Tools (1) -verbose:gc Commandline Parameter – Erzeugt GC Informationen nach stdout -Xverbosegclog: – Erzeugt GC Informationen nach stdout
Commandline Tools (2)
IBM Trace Funktionalität
– -Dibm.dg.trc.print=st_verify
• Analyse von Pinned Objects
GC(VFY-SUM): pinned=79(classes=2/freeclasses=0) dosed=85 movable=4609 free=1886
GC(VFY-SUM): freeblocks: max=37080 ave=184 (347384/1886)
GC(VFYAC-SUM): freeblocks: max=94504 ave=7389 (347328/47)
– -Dibm.dg.trc.print=st_terse
• Analyse der Objekte vor und nach GC
*DH(1)* 0x10063244 a x0x50 java.util.HashMap$Entry[16]
*DH(1)* 0x10063294 a x0x20 java.lang.String@10063298/100632A0
*DH(1)* 0x100632b4 a x0x18 "float"
*DH(1)* 0x100632cc a x0x30 java.util.HashMap@100632D0/100632D8
*DH(1)* 0x100632fc a x0x10 java.lang.Object@10063300/10063308IBM Garbage Analyser (1)
IBM Pattern Modeling and Analysis Tool for GC
– IBM alphaworks Produkt
– Grafische Analyse der –verbose:gc Ausgaben
– Ermitteln der prozentualen und absoluten Zeiten für
• Marc
• Sweep
• Compact
• GC
– Ermitteln von Heap StatistikenIBM Garbage Analyser (2)
IBM Heapdump (1) Erzeugen eines Heapdumps – Explizit (kill -3 oder WebSphere DrAdmin Utility) – JVM Triggered (OutOfMemoryError) Analyse der Objekte im Heap – Größe von Caches, Session, etc. – Analyse von Memory Leaks Steuerung über Environment Variablen – IBM_HEAPDUMP=true – IBM_HEAPDUMP_OUTOFMEMORY=true – IBM_HEAPDUMPDIR= – IBM_HEAPDUMP_TEXT=true
IBM Heapdump (2) // Version: J2RE 1.4.1 IBM AIX build cadev-20030722 0x30270200 [388832] byte[] 0x302cf0e0 [304] class HeapConsume 0x302cf210 [50232] byte[] 0x302db648 [128] sun/misc/Launcher$AppClassLoader ...............(more data)................ // Breakdown - Classes: 321, Objects: 2624425, ObjectArrays: 486, PrimitiveArrays: 1447 // Meta-data - NullRefs: 2623863, Mark(m): 2626359, Alloc(a): 0, Dosed(d): 13, Pinned(p): 0, MultiPinned(P): 0 // EOF: Total ’Objects’,Refs(null) : 2626679,2629818(1797)
IBM Heap Analyser (1)
IBM Heap Analyser
– IBM alphaworks Produkt
– Grafische Analyse der IBM Heapdumps
• Binär
• Text
– Automatische Identifikation potentieller Memory Leaks
Alternative: JProbe Memory Debugger
– Einlesen von IBM Heapdumps im Textformat möglich
– Mächtiges AnalysewerkzeugIBM Heap Analyser (2)
JProbe Überblick JProbe Suite – JProbe Profiler (Laufzeitanalyse) – JProbe Memory Debugger (Speicherverhalten) – JProbe Coverage (Codeabdeckungsanalyse) Existiert schon lange, hoher Bekanntheitsgrad Alternativen: WSAD (Hyades), JProfiler, YourKit
JProbe Architektur
JProbe Suite basiert auf einheitlicher Architektur
Java
Anwendung
JProbe
Console Protocol over
Connection Analysis
TCP / IP JVM
Manager Engine
JVM
JProbe Console (jpprofiler, jpmemorydebugger, jpcoverage)
JProbe Analysis Engine (jplauncher)
JVMPI (JVMTI in Version 7)JProbe Profiler JProbe Profiler – Callgraph – Hotspot Analyse – Bis auf Zeilenebene
JProbe Memory Debugger JProbe Memory Debugger – Memory Leaks – Cycling Objects – GC – Object Creation IBM Heapdump Import
Tivoli Performance Viewer (1) Seit WebSphere 6 in Admin Console integriert
Tivoli Performance Viewer (2) Application Statistics – Servlet Response Times – EJB Methoden Response Times WebSphere Runtime Statistics – Thread Pools – Database Connections Pools System Statistics – CPU Utilization
Tivoli Performance Viewer (3)
Advisor
– Hinweise zum Tuning des Systems auf Basis der TPV
Statistiken
Ergebnisberichte
– Servlets
– EJBs/EJB-Methoden
– Verbindungs- und Threadpools
Leistungsmodule
– Charts- und Performance Daten zu CPU, Memory,
WebSphere Ressourcen und ApplikationenPerformaSure Architektur
PerformaSure Tag&Follow
PerformaSure Überblick
Bytecode Instrumentierung für wenig Overhead
– 3%-10% je nach Details und Zeitintervall
Agenten für Java, http-Server und System
nexusctl – Commandline Utility
– Starten und Stoppen von Messungen
– Konfiguration der Messung mit identischer
Funktionalität wie Workstation
Alternativen: Wily Introscope, ITCAMTuning Best Practises
Allgemein (1)
System und Entwicklung müssen zusammenarbeiten
– Oft unterschiedliche Umgebungen
– Verständnis für das System fehlt bei Entwicklern
– Anwendungsarchitektur hat Auswirkungen auf das Systemdesign
– Managebarkeit von Anwendungen einfordern!
Performance/Memory als Architektur- und Designtreiber
– Immer hohe Priorität, langsame oder instabile Anwendungen habe keine Akzeptanz
– Fokus auf diese Treiber in einer frühen Phase
– Definition von messbaren Zielen wichtig
Die Applikation sollte korrekt funktionieren, bevor sie getuned wird
– Bugfixing/Weiterentwicklung und Tuning stören sich gegenseitig
– Konzentration auf Tuning, nicht auf Bugfixing
– Inkrementelle Vorgehensweise in kurzen Intervallen mit ständigem Tunen trotzdem möglich
Sauberes Design und intensive Verwendung von Schnittstellen vereinfacht das
Tuning
– Kapselung Methoden/Algorithmen/Zugriffe hinter definierten Schnittstellen
– Macht die Implementierungen austauschbar, wenn diese Probleme verursachenAllgemein (2)
Tuning entspricht einem Refactoring
– Automatisierte Testfälle vor dem Tunen zum Verifizieren der Funktionalität
– Messung des Erfolgs der Maßnahme durch Profiler
Verifikation der Performance-Zahlen durch ständige Lasttests
– früh in der Entwicklungsphase (auch schon Prototypen)
– Pre-Production und Production oft zu spät
– Vermeintliche „Kleinigkeiten“ können unter Last zu Hotspots werden
Fokus immer auf Hotspots, kein Verzetteln in Details
– Oft hoher Aufwand in Detailtuning, was in keinem Verhältnis zum Gewinn steht
Effektives Produktionsmonitoring für Performance/MemorySkalierbarkeit (1)
Ziele von Skalierung
– Parallelisierung von Prozessen für höheren Durchsatz
– Ausschalten des Single-Point-of-Failure für bessere Verfügbarkeit
Horizontales Clustering
– Mehrere JVM Instanzen (Application Server) auf mehreren physikalischen Servern
– Skalierung für Failover und/oder Performance möglich
Vertikales Clustering
– Mehrere JVM Instanzen (Application Server) auf einem physikalischen Server
– Bessere Auslastung der CPUs und optimale Heap Konfiguration
Load-Balancing
– Verteilung von Anfragen (JMX, RMI, HTTP) auf verschiedene Application- oder
Webserver basiert aus IP, User, Content, Auslastung, etc.
– Sticky Sessions für Load-Balancing ohne Failover für maximale PerformanceSkalierbarkeit (2) WebSphere Edge Components – Load Balancer – Caching Proxy
Performance – Übergreifend Java SE / EE
Logging
– Verwenden eines Logging-Frameworks
– Abfragen des Logging-Levels vor dem Erstellen der Log-Nachricht
– Minimales aber richtiges Logging in Produktionsumgebungen
– Kein System.out.println
Verwenden von Frameworks
– Oft schon gute Performance
– Richtige Verwendung!
JMX für Management und Monitoring nutzen
– In WebSphere deklarativ über XML möglich
– In zOS Umgebung bei mehreren Servants unumgänglich!
(multicall)Performance – Datenbank Minimierung der Anzahl an Zugriffen – DB oft auf anderen Rechnern Caching auf Resultset-Ebene (oder logische Anwendungsebene darüber) – aber nicht direkt JDBC-Resultsets (Offene Cursor) Nutzung von Prefetch-Möglichkeiten Verwendung von Frameworks an Stelle von eigenen JDBC-Zugriffen – Oft Caching-Möglichkeiten „umsonst“ dabei – Meistens schon sehr gute Performance Nutzung von Connection Pooling – WebSphere DataSource – Optimierung der Größe Optimieren der SQLs und Indizes – Analyse des Anwendungsverhaltens – DBA einschalten! Spezifische JDBC Treiber Optimierungen Nutzen
Performance – Java EE (1)
HTML
– Bilder/CSS/JavaScript/statisches HTML vom Webserver, nicht vom Application Server
– Zippen am Webserver einstellen, wenn Leitungskapazität ein Problem ist
– Auslagern von JavaScripts/Style-Informationen in Dateien um Caching der Browser zu
nutzen, dynamisch erzeugte HTMLs klein halten
– Edge Server Caching Proxy verwenden
JSP
– Caching teurer JSPs oder Teile davon mit WebSphere Dynamic Caching
• WebSphere Dynamic Caching unterstützt auch Struts und Tiles
– Zerlegung einer JSP, wenn Teilelement teuer und dieses gecached werden kann
– Saubere Kapselung in Custom Tags vereinfacht oft das Performancetuning
XSL
– Template-Caching und -kompilierung bei Verwendung von Apache Xalan (XSLTC)Performance – Java EE (2)
EJB
– Nutzung von Tuningfähikgeiten des Applicationservers (Prefetch, Isolation Level, etc.)
– Caching der EJB-Homes
– Wenn Entity-Beans nur für Datenbank-Zugriff, dann Lightweight-OR-Mapper verwenden
– Minimierung der Remote-Aufrufe
Servlets
– Max. Anzahl Threads beachten (abhängig von Plattform)
– Vermeiden von „synchronized“ in Servlets oder aus Servlets heraus
– Wenn Webserver „Zippen“ der Ausgabe zur Minimierung der Leitungsbelastung nicht
kann, dann zentral implementieren (z.B. durch Filter), Abwägen Leitung vs. Prozessor
– Redirects sind langsamer als Forwards, da der Browser einen neuen Request auslöst
(Verzweigen innerhalb der Webapplikation oder Kontext-übergreifend)
– Bei Verwendung der WebSphere Command Framework API auch Command Caching
möglichPerformance – Java EE (3)
HTTP-Session
– Keine großen Objektbäume in Session speichern, zu große Sessions verhindern
Optionen zur Skalierbarkeit
– Kapselung des Zugriffs an zentraler Stelle
– Explizites Invalidieren der Session (nicht auf Timeout verlassen)
– Session-Timeout-Intervall möglichst klein halten
– Verwendung von „transient“ für reproduzierbare Daten bei serialisierbaren SessionsPerformance – Caching (1)
Caching auf allen Ebenen möglich
– Edge Server Caching Proxy
– Servlet/JSP result caching (WebSphere Dynamic Caching)
– Command Caching (WebSphere Dynamic Caching)
– DB Zugriff (OSCache, JBoss Cache)
• First Level: Caching im JDBC Treiber, auf ResultSet Eebene
• Second Level: Caching ganzer Objektbäume für Abfragen (Hibernate)
Replikation der Daten im Cluster bei WebSphere Dynamic Cache und
JBoss Cache möglich
Caching in Abhängigkeit der JVM prüfen!Performance – Caching (2)
Memory – Tipps (1)
Erst Memory-Leaks fixen, dann Performance tunen
Wiederholbarer, definierter Use Case, am besten automatisiert
– Unsystematisches „Rumklicken“ in der Anwendung nicht sinnvoll
– Use Case durch Beobachten des Heaps/GCs verifizieren
– Sicherstellen, dass Leak vorhanden ist
Heap-Größe bei Untersuchung möglichst klein halten
– Verringert die zu untersuchende Datenmenge
Caches und Pools auf kleinen Wert beschränken
– schlechtere Antwortzeiten durch kleine Caches/Pools sind hier egal
– Caches werden oft fehlerhaft als Leak identifiziert
– Nicht immer möglich, z.B. bei parallelen Zugriffen und fehlerhaften Abbruch bei
„leerem“ PoolMemory – Tipps (2) HTTP-Session – Use Case sollte so geschnitten sein, dass die HTTP-Session immer invalidiert wird – Falls dies nicht möglich, Session Timeout sehr gering wählen – Vor dem Debuggen sollte Session-Klasse bekannt sein Heap einer Anwendung dauernd überprüfen – Einsatz von Monitoring-Tools Änderungen an den GC-Einstellungen auch immer unter Last verifizieren – Was für einzelne Zugriffe gut ist, kann unter Last schlecht sein Auch eine Untersuchung von „Allocation“-Hotspots kann auf ein Memory Leak hindeuten
Memory – Tipps (3)
Symmetrien bei Anlegen von Referenzen schaffen
– Wenn eine Methode eine Referenz schafft, muß es eine geben, die diese wieder lösen
kann
Untersuchung des Speicherverhaltens an kritischen Punkten früh in
der Entwicklung
– Verifizierung von Hypothesen
Dokumentation der Schnittstellen
– Design by Contract : Was passiert mit übergebenen Objekten?
– In einer Referenz-schaffenden Methode auf die Methode zum Löschen der Referenz
verzweigen
Eingesetzte „externe“ Frameworks müssen diesbzgl. verstanden
werdenSie können auch lesen
