Implementierung%20und%20Managment%20unternehmenskritischer%20Anwendungen%20insbesondere%20Performance%20und%20Skalierbarkeit%20EJB%20basierter%20Anwendungen

1
Implementierung 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

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
• gt 1400 Kunden, davon nutzen ca. 600 EJB
• Mittlerweile zahlreiche Erfahrungen aus
  Projekten.....

1999
1998
1997
1996
1995
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