Title: Implementierung%20und%20Managment%20unternehmenskritischer%20Anwendungen%20insbesondere%20Performance%20und%20Skalierbarkeit%20EJB%20basierter%20Anwendungen
1Implementierung und Managment unternehmenskritisch
er Anwendungeninsbesondere Performance und
Skalierbarkeit EJB basierter Anwendungen
Thomas WalterManager Enterprise Java GroupBEA
Central Eastern Europemailto
thomas.walter_at_beasys.com
- WebLogic, das Herz von Java
2Inhalt
- Einführung BEA WebLogic
- Skalierbarkeit Performance
3Einfü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
- gt 1400 Kunden, davon nutzen ca. 600 EJB
- Mittlerweile zahlreiche Erfahrungen aus
Projekten.....
1999
1998
1997
1996
1995
4Inhalt
- Einführung BEA WebLogic
- Skalierbarkeit Performance
5Skalierbarkeit 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
6Was 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
- 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
8Verantwortlichkeiten
- 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.
9Flaschenhälse veranschaulicht
- Jeder Knoten und jede Verbindung ist ein
potentieller Flaschenhals
10Flaschenhä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
11Flaschenhä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
12Generelle 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
13Kennen 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
14Mythos 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
15State 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
16Verkehr zwischen Appserver und Client 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
17Optimierung 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
18Reduktion von Verkehr zw. App- und DB-Servern
- Reduktion der übertragenen Datenmenge
- Umsichtiger Gebrauch von AppServer Caches
- Denormalisierung
- Reduktion der Request-Anzahl
- Bulk-Zugriff
- Stored Procedures
19Datenbankoptimierung
- 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
20Was 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)
21Flexible 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
22Was 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
23Was die EJB Spezifikation benötigt
- Massen CRUDs
- Relationships
- und effiziente Traversierung von Relationships
- Explizite Aktivierungs- / Deaktivierungs-Policies
- Verbindung zwischen EJB Container und JMS