implementierung und managment unternehmenskritischer anwendungen insbesondere performance und...
TRANSCRIPT
Implementierung und Managment Implementierung und Managment unternehmenskritischer Anwendungenunternehmenskritischer Anwendungen
insbesondere insbesondere Performance und Skalierbarkeit Performance und Skalierbarkeit
EJB basierter AnwendungenEJB basierter Anwendungen
WebLogic, das Herz von Java™
Thomas WalterThomas WalterManager Enterprise Java GroupManager Enterprise Java GroupBEA Central & Eastern EuropeBEA Central & Eastern Europe
mailto: [email protected]: [email protected]
2
InhaltInhalt
Einführung BEA WebLogic Skalierbarkeit & Performance
3
Einführung BEA WebLogicEinführung BEA WebLogic
Gegründet als WebLogic Inc., seit Sept. 98 BEAs WebXpress Division
100% Java, EJB seit Sept. 97
Clustered EJB seit Nov. 98 > 1400 Kunden, davon
nutzen ca. 600 EJB Mittlerweile zahlreiche
Erfahrungen aus Projekten.....
1999
1995
1996
1998
1997
4
InhaltInhalt
Einführung BEA WebLogic Skalierbarkeit & Performance
5
Skalierbarkeit und PerformanceSkalierbarkeit und Performance
Systeme wachsen in vieler Hinsicht Benutzer, Daten, Transaktionskomplexität
Ein System skalieren heißt Hardware addieren und Konfigurationsparameter
ändern um Durchsatz zu erhalten oder zu erhöhen Keinen Applikations-Code oder Datenbankschemas
zu ändern Sicherstellen, daß zusätzliche Hardware ausgelastet
wird
6
Was reduziert Skalierbarkeit?Was reduziert Skalierbarkeit?
Die gleichen alten Ursachen Konkurrenz um Daten Konkurrenz um Prozeßeinheiten
CPUs, Threads
Konkurrenz um Resourcen Database Connections Memory, Disk, I/O channels
7
...plus einiger neuen Tücken...plus einiger neuen Tücken
Geschwindigkeit des Deployments Verringertes Time to Market Rapide Skalierung nach Veröffentlichen der URL
Verteilte Objekte und Komponenten Einfachheit der Benutzung und verführerische
Transparenz
Technologische Heterogenität Web Server, Middleware, Datenbanken
Performance-Belange werden vergessen bis es zu spät ist
8
VerantwortlichkeitenVerantwortlichkeiten
Jeder hat Verantwortung zur Schaffung von Skalierbarkeit EJB-Designer
benötigen umfassende Sicht, nicht middleware- oder datenbankzentrisch
Müssen wissen welche Verbesserungen gemacht werden können nachdem System deployed ist
Server-Hersteller Autoren der EJB Spezifikation bei Sun
Wie bei ACID Transaktionseigenschaften Atomar, Consistent, Isoliert, Dauerhaft: C kommt
durch Applikation.
9
Flaschenhälse veranschaulichtFlaschenhälse veranschaulicht
Jeder Knoten und jede Verbindung ist ein potentieller Flaschenhals
10
Flaschenhälse an KnotenFlaschenhälse an Knoten
Appserver Threads blockiert durch DB oder Monitore Unnötig hohe Anzahl an request-handling Threads Garbage Collection
Datenbankserver Shared Data Unnötig strenge Isolationlevels
Profiler helfen, aber erfassen keine größeren Muster
11
Flaschenhälse an VerbindungenFlaschenhälse an Verbindungen
Client zu Appserver Business-Methoden, remote Garbage Collection,
keep-alive Traffic
Zwischen Appservern Concurrency und Caching-Protokolle, verteilte
Transaktionen, Objekt-Lokation
Appserver zu Datenbank Zwischen Datenbank-Servern
Verteilte Transaktionen und Lockmanagment
DB Server zu Disk
12
Generelle EmpfehlungenGenerelle Empfehlungen
Zielgerichtetes Design: Zuerst UI Höchste Aufmerksamkeit gilt Anwender:
Benutzbarkeit und Performance müssen primäres Ziel sein
Applikations-Designer kommt zuerst, danach der Bean-Designer
Performance-Analyse planen Zur Design-Zeit wissen, wo Hooks gesetzt werden
und wie die Daten analysiert werden
Kennen Sie Ihre Anwendung, kennen Sie die HotSpots
13
Kennen Sie Ihre AnwendungKennen Sie Ihre Anwendung
E-Commerce Applikationen Viele Clients, hohes Lese / Update Verhältnis, wenig
Konkurrenz, großes Datenset
Netzwerk Managment Systeme Wenige Operatoren, einige HotSpot Netzwerkknoten
Banken und Bankomaten Viele Clients, wenig Gleichzeitigkeit, hoher Isolation-
Level, kein Datenset
Ermitteln Sie Datenset, Gleichzeitigkeit und Update-Erfordernisse aus Use-Cases
14
Mythos: Stateless == SkalierbarMythos: Stateless == Skalierbar
„Stateless == Skalierbar“ ist bedeutungslos Es gibt immer Zustand: Frage ist wo lebt er? Stateless Middleware garantiert daß Middleware kein
Flaschenhals ist Was machen Sie wenn Datenbank zum Flaschenhals
wird?
Zustand ist nützlich Datenbanken besitzen Caches, HTTP besitzt Cookies In E-Commerce Applikationen wird zu 90% gebrowsed Je geringer Anforderung an Cache-Kohärenz, desto
näher kann Cache an Client liegen
15
State verwaltenState verwalten
Parameterisierte Caches Dauer, Menge, Concurrency und Replikation
Wenn möglich getrennte Caches für Lesen und Schreiben
Redesign wenn hoher Anteil geshared wird Frontends auf Queue Requests umstellen Shared Updates ans Transaktionsende verlagern
Entity Beans nur für shared Data Non-shared Data wird komplexes Attribut
16
Verkehr zwischen Appserver und Verkehr zwischen Appserver und Client reduzierenClient reduzieren
UI spricht mit nur einer Bean (typisch: Session)
Verwenden Sie grobkörnige Interfaces Daten bulk übertragen IDL Attribute vermeiden Nur Daten sollten dieses Interface passieren, keine
Referenzen
Vermeiden Sie Client-Transaktionen Verwenden Sie Servlets statt Applets
17
Optimierung am AppserverOptimierung am Appserver
Verkehr zwischen Appserver-Prozessen Vermeiden verteilter Transaktionen Anfragen partitionieren und an entsprechenden
Appserver verteilen
Langlaufende Transaktionen vermeiden Lesende von Schreibenden möglichst
trennen Benutzen Sie Java™ Message Service (JMS)
um Requests zu serialisieren
18
Reduktion von Verkehr zw. App- und Reduktion von Verkehr zw. App- und DB-ServernDB-Servern
Reduktion der übertragenen Datenmenge Umsichtiger Gebrauch von AppServer Caches Denormalisierung
Reduktion der Request-Anzahl Bulk-Zugriff Stored Procedures
19
DatenbankoptimierungDatenbankoptimierung
Daten Partitionierung DB-Log auf solid-state Disks legen Modifizieren von SQL Statements um
Optimizer-Hints Nicht in Queries benötigte Attribute sind
BLOBs Erweiterte DBMS Features verwenden
20
Was können Appserver beitragen?Was können Appserver beitragen?
State Managment Konfigurierbare Policies anbieten Activation und Deactivation-Policies
Deaktiviere nach Timeout, nach Methode, nach Transaktion, niemals
Aktiviere auf Anforderung
Concurrency (optimistisch, pessimistisch) Caching (mit verschiedenen Isolation-Levels)
21
Flexible Caching StrategienFlexible Caching Strategien
Hängt ab von Lese- / Schreibmuster und Toleranz gegenüber Cache-Inkohärenz
Strategien Nur ein Ort für primary Key Viele Instanzen (für einen primary Key) die zu jeweils
anderen Servern sprechen Viele Instanzen, die nur über DB kommunizieren
22
Was können Appserver beitragen...Was können Appserver beitragen...
Daten-Partitionierung Factory based Routing Data-dependent Routing
Connection Managment Keine TCP Connections von n Clients zu m Servern
Objekt- und Resource-Pooling Transparentes Failover und Failback Monitoring Hooks für Requests, Datenbank-
Treiber, Caches
23
Was die EJB Spezifikation benötigtWas die EJB Spezifikation benötigt
Massen CRUDs Relationships
und effiziente Traversierung von Relationships
Explizite Aktivierungs- / Deaktivierungs-Policies
Verbindung zwischen EJB Container und JMS