Implementierung und Managment unternehmenskritischer Anwendungen insbesondere Performance und Skalierbarkeit EJB basierter Anwendungen WebLogic, das Herz von Java Thomas Walter Manager Enterprise Java Group BEA Central & Eastern Europe mailto:

2 Inhalt Einführung BEA WebLogic Skalierbarkeit & Performance

3 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

4 Inhalt Einführung BEA WebLogic Skalierbarkeit & Performance

5 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

6 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 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 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.

9 Flaschenhälse veranschaulicht Jeder Knoten und jede Verbindung ist ein potentieller Flaschenhals

10 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

11 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

12 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

13 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 Isolation- Level, kein Datenset Ermitteln Sie Datenset, Gleichzeitigkeit und Update-Erfordernisse aus Use-Cases

14 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

15 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

16 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

17 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

18 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

19 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

20 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 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... 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ötigt Massen CRUDs Relationships und effiziente Traversierung von Relationships Explizite Aktivierungs- / Deaktivierungs- Policies Verbindung zwischen EJB Container und JMS