ppt-Datei

Implementierung und Managment
unternehmenskritischer Anwendungen
insbesondere
Performance und Skalierbarkeit
EJB basierter Anwendungen
Thomas Walter
Manager Enterprise Java Group
BEA Central & Eastern Europe
mailto: [email protected]
WebLogic, das Herz von Java™
Inhalt
 Einführung BEA WebLogic
 Skalierbarkeit & Performance
2
Einfü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.....
3
1999
1998
1997
1996
1995
Inhalt
 Einführung BEA WebLogic
 Skalierbarkeit & Performance
4
Skalierbarkeit 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
5
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
6
...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
7
Verantwortlichkeiten
 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.
8
Flaschenhälse veranschaulicht

Jeder Knoten und jede Verbindung ist ein potentieller
Flaschenhals
9
Flaschenhä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
10
Flaschenhä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
11
Generelle 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
12
Kennen 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 IsolationLevel, kein Datenset
 Ermitteln Sie Datenset, Gleichzeitigkeit und
Update-Erfordernisse aus Use-Cases
13
Mythos: 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
14
State 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
15
Verkehr 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
16
Optimierung 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
17
Reduktion 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
18
Datenbankoptimierung
 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
19
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)
20
Flexible 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
21
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
22
Was die EJB Spezifikation benötigt
 Massen CRUDs
 Relationships
 und effiziente Traversierung von Relationships
 Explizite Aktivierungs- / Deaktivierungs-
Policies
 Verbindung zwischen EJB Container und
JMS
23