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: thomas.walter@beasys.commailto: thomas.walter@beasys.com

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