leistungssport - oio · 1 orientation in objects gmbh weinheimer str. 68 68309 mannheim version:...

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]: 0.3

LeistungssportPerformance-Aspekte großer JavaServer-Faces-Projekte

2

© 2009 Orientation in Objects GmbHPerformance-Aspekte großer JSF-Projekte

Die Sprecher - Oliver Wolff & Christian Dedek

2

3


) Competence Center)) Object Rangers )

Java, XML und Open Source seit 1998

• Schulungen, Coaching, Weiterbildungsberatung, Train & Solve-Programme• Methoden, Standards und Tools für die Entwicklung von offenen, unternehmens- weiten Systemen

• Unterstützung laufender Java Projekte

• Perfect Match• Rent-a-team• Coaching on the project• Inhouse Outsourcing

• Schlüsselfertige Realisierung von Java Software

• Individualsoftware• Pilot- und Migrationsprojekte• Sanierung von Software• Software Wartung

) Software Factory )

4


Die Themen

Beyond JSF

State SavingAjax

Wundertüte

3

5


Was ist Groß?

100 Views100 Views

500 Benutzer500 Benutzer100 MB/h Durchsatz100 MB/h Durchsatz

100 Entwickler100 EntwicklerViel zu teuerViel zu teuer

6


Performance und Skalierung

Wicket ist 2-4 malschneller als JSF

Wicket ist 2-4 malschneller als JSF

Blog Peter Thomas

Struts ist 4-9 malschneller als JSF

Struts ist 4-9 malschneller als JSF

Entwickler.de

JSF ist nur etwasfür das Intranet

JSF ist nur etwasfür das Intranet

Man darf das Backend nicht vergessen

Man darf das Backend nicht vergessen

4

7


Entwicklungs- vs. Laufzeitskalierung

• Komponentenmodel– Beschleunigt die Entwicklung– Laufzeit– Kein Zauberstab

• Lebenszyklus– Laufzeit– Zeit zum Verständnis: immediate?– Definiert Ablauf

8


Übersicht

State Saving

5

9


Übersicht

• Zustand einer Anwendung

• Beinhaltet– Infrastruktur: Komponenten, Views, ...– Daten / Beans– !! Serialisierung von Beans

• Beobachtete State-Größen– 100 KB– 250 KB– 2 MB

10


Server vs. Client

Server

Anwendung

Client

Zustand

Zustand

Server

Anwendung

Client

RealmRealm

RealmRealmZustand

6

11


Server vs. Client

• Server Side:– Context Incomplete: Back Button & Reload,..– Ist die Regel– Bessere Antwortzeiten– Skaliert schlechter

• Client Side:– Context Complete– Besser für Clustering– Kein Speicherverbrauch zwischen Requests– Braucht mehr Bandbreite– Zusätzlichen Aufwand für Sicherheit

12


Server 3

jsf-state

Server 2

jsf-state

Server 1

jsf-state

State bei Clustering von HTTP Anfragen

Loadbalancer DB

AJP

AJP

AJP

HTTP

jsf-statejsf-state

jsf-statejsf-state

jsf-state

7

13


Optimierung I

• Session möglichst klein halten

• Verbesserung durch alternativen SerialisierungsProvider– Beispiel JBossSerializationProvider– Bei vielen parallelen Benutzern: bis 30% weniger CPU-Last

• Baum (De-) Serialisierung sehr teuer (CPU)

• „Je Ajax, desto Server“– Zumindest bei JSF-Ajax

14


Optimierung II

• Serialiserung, auch serverseitg– com.sun.faces.serializeServerState– org.apache.myfaces.SERIALIZE_STATE_IN_SESSION

• Komprimierung– com.sun.faces.compressViewState– org.apache.myfaces.COMPRESS_STATE_IN_SESSION

• Abwägen: Speicher vs. CPU

8

15


Session Size bei serverseitiger Skalierung

• Speicher begrenzt Zahl der möglichen Sitzungen pro Knoten• GC-Overhead steigt mit Größe des Heap

• 32-Bit– bis zu 1,5 GB Heapsize problemlos nutzbar– oft bessere Antwortzeiten pro Request– geringerer GC-Overhead

• 64-Bit– Verfügbarkeit und Reife der Kombination J2EE-Server/JVM/OS ?– GC-Overhead– teilweise schlechtere Antwortzeiten(Prozessor-Taktraten)– Kosten ?

16


Skalierungsproblem Session Replication

TCP Loadbalancer

ReplicationValve

ReplicationManager

Context /app

Name Wert

umsatz 5000

datum 28.9.2003

positionen

10, Tee

2, Kaffee

50, Lolly

Session

ReplicationValve

ReplicationManager

Context /app

Name Wert

umsatz 5000

datum 28.9.2003

positionen

10, Tee

2, Kaffee

50, Lolly

Session

ReplicationValve

ReplicationManager

Context /app

Name Wert

umsatz 5000

datum 28.9.2003

positionen

10, Tee

2, Kaffee

50, Lolly

Session

Multi-cast

Multi-cast

9

17


Lösungssszenario: Partitionierung von Zuständen

Partition „Share 1“Partition „Share 1“

Knoten A

Sub-Partition „Share 2“Sub-Partition „Share 2“Sub-Partition „Share 1“Sub-Partition „Share 1“

Knoten A Knoten B

Knoten A Knoten B Knoten X Knoten Y

18


Best Practices - Umgang mit Managed Beans

• Eine Request-Scope-Bean / View

• Eine SessionBean pro Anwendung / Modul

• Definierter Dialog-Mechanismus– Shale, Orchestra, Seam, ...

• PageScope über Erweiterung– JSFTemplating– PrimeFaces Optimus: ViewScope– JSF 2.0

10

19


Anforderungen an die Zukunft I

• Überdenken Konzept der Zustandsbehaftung– REST ist in aller Munde– RestFaces / PrettyFaces– Mainstream WebBeans / Seam

• Zielrichtung für JSF-Anwendungen?

• Scope– PageContext: JSF 2.0– Dialog

20


Anforderungen an die Zukunft II

• Tokenize a´la ADF– Zumindest „Context Complete“ für Server Side

• Implementierungen– (De-) Serialisierung– Speicherverbrauch: Bravo MyFaces– Fokus auf Client

• Delta-State-Saving

11

21


Übersicht

Ajax

22


Spannungsfelder Ajax - Übersicht

• Ajax verstehen– Eye Candy vs. Usability

• Nicht alles Mögliche ist sinnvoll

• Sinnvolles muß möglich sein

• Einheitliche Verwendung

• Kapselung reicht nicht aus– Verständnis muß gegeben sein

12

23


Spannungsfelder Ajax - Übersicht II

• Unterschiedliche Ansätze– Selten kompatibel– Möglichkeit der Vereinheitlichung

• JSF 1.2: invokeOnComponenet() & DynaFaces

• RichFaces & IceFaces?

• Kapselung gegenüber Handarbeit

• Woodstock & DojoInitializer?

24


Spannungsfelder Ajax - Aus der Praxis

RichFacesrockt!

RichFacesrockt!

Echte Männernehmen Dojo

Echte Männernehmen Dojo

13

25


Ajax Strategien - Dick & Dünn

ProgrammierModell?

ProgrammierModell?

? ?

Dojo

JSF-Stub

FatClient

Ajax-Servlet

DatenDaten

Ajax?DHTML?Ajax?

DHTML?

Ajax-ServletAjax-Servlet

Ajax-Servlet

Ajax-Komponenten

Anwendung

Client

RealmRealm

RealmRealm

Komponente

DatenDaten, HtmlJavaScript

26


Ajax Strategien - Woodstock - Dojo

14

27


Spannungsfelder Ajax - Auflösung

• Es gibt keine perfekte Bibliothek

• Am Framework vorbei skaliert schlecht: Dojo, jMaki

• Mehrere gleichzeitige Ansätze sind tödlich

• Wenn FatClient, dann richtig: Woodstock

28


Anti-Patterns - Partial Form Processing

...<h:inputText value="#{messageBean.message}" id="nameInput">

<a4j:support event="onkeyup"/><f:validateLength minimum="3" />

</h:inputText>

...

<a4j:support event="onblur"/>

15

29


Best Practices - Partial Page Rendering

• Ziel: Desktopanwendung– Fenster nur verändert

• Ajax: Partial Page Rendering

• Entwickler müssen in passenden Strukturen denken– Modularisierung der Seite in beide Richtungen

• Beispiel: RichFaces reRender-Attribut– Nicht vergessen: Gesendete Daten– Hilft weniger bei Client Side State Saving

30


Ajax Optimierung, Beispiel RichFaces

• Wichtige Attribute:– reRender, ajaxRendered– a4j:region, renderRegionOnly, limitToList– ajaxSingle, process– eventQueue, requestDelay, ignoreDupResponses

• Auswahl des richtigen Filters– Tidy: Korrigiert sehr aufwändig– Neko: Korrigiert weniger aufwändig, deutlich schneller– None: Macht gar nichts, schnellste Variante– forceparser

16

31


Anforderungen an die Zukunft

• Kompletter AjaxStack als Teil der Implementierung JSF 2.0

• Zusammenarbeit Komponentenentwickler– Austauschbarkeit– ziemlich naiv

• Schnelle Integration neuer Technologien

32


Übersicht

Wundertüte

17

33


Der richtige ViewHandler

ShaleICEFaces

JSF Core

Facelets JSFTemplatingJSP

Laufzeitgewinn: 10-30%

X

34


Context Parameter - Response Buffer

• Produktive Anwendung, oberer Lastbereich• Responsezeiten, Angaben in Prozent

facelets.BUFFER_SIZE=50k responseBufferSize=50k

10092,8

64,4

0

20

40

60

80

100

120

18

35


Passende Designs - Datentabelle - Übersicht

• Datentabelle

• Häufige Anforderung: 100 Zeilen+

• Problem: Vielfache EL-Evaluierung, einige Sekunden Ladezeit

Lösung: „Richtige“ Datentabelle

36


Passende Designs - Datentabelle - Woodstock

19

37


Komponenten vs. Anwendungsframework

• JSF ist ein UI-Framework für Webanwendungen“

• JSF Design:– Fokus auf Komponenten-APIs– Lebenszyklus nicht perfekt– Aber: Alle Framework-Aspekte leicht erweiterbar

Grundlage für Anwendungs-Frameworks

JSF = Komponenten-Framework

Ziel: Anwendungsframework für konkretes Projekt– Architektur, kein Wildwuchs– Schulung der Entwickler

38


Übersicht

Beyond JSF

20

39


Schlüsselqualifikationen

• Qualifikation im JSF-Dschungel

• Reproduzierbarkeit im nichtfunktionalen Systemchaos– Teststrategien– deduktive Systematik

• Kommunikation und Feedback– Einsatz von Issuetrackern– Produktion Management-Summaries und Reports

40


Probleme mit 3rd Party

• Apache Datenbankpool hat nicht skaliert– fixed mit dbcp-1.2.2, pool-1.3,collections-3.2 Mitte 2006

• Concurrency issue (race condition) in unserem ApplicationFramework– z.B. Hibernate HHH-1486 fixed 3.2.0 Feb. 2006– Trat nur im stochastischen Lastverhalten auf– nicht deduktiv reproduzierbar

21

41


Stabilitätsproblem Threadlocal

• Bei Analyse des Benchmarks tritt ein moderates memory leak auf.– JDK 1.4 war dagegen fehlertolerant, der Fehler trat erst mit JDK 1.5

auf– Ursache war die falsche Verwendung des „thread local“ API– Der Bug wurde mehrfach wieder geöffnet, weil die API an mehreren

Stellen aufgerufen wurde

• Vergleiche– http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html– http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html

• Der kleine Unterschied:– public void remove()

• Removes the value for this ThreadLocal

42


Lost Cleanup - Thread local bug ?

Thread-Local

XY-Scope

CollectionContainer/Framework

Container/Framework

Application

3. cleanup()

1. store()1.x set() 2.x get()

2. get()

Exceptions ?

3.x remove()

22

43


Lost Cleanup - Example

Siehe: http://jira.atlassian.com/browse/CONF-14988

44


JDK Concurrency Problem ? java.beans.Introspector

Introspector

Bean

Framework

getBeanInfo()Bean

Framework

getBeanInfo()Bean

Framework

getBeanInfo()Bean

Framework

getBeanInfo()Bean

Framework

getBeanInfo()

Frameworks nutzen zum Zugriff auf Beans Reflection über jdk-Utility

23

45


java.beans.Introspector

• Sun-Implementierung:– Zugriff

BeanInfo bi = (BeanInfo)beanInfoCache.get(beanClass); if (bi == null) { bi = (new Introspector(beanClass, null,

USE_ALL_BEANINFO)).getBeanInfo(); beanInfoCache.put(beanClass, bi);

– Deklarationprivate static Map beanInfoCache =Collections.synchronizedMap(new WeakHashMap());

• effektiv führt dies zu einer Synchronisation der Methode

46


Introspector & JSF

24

47


java.beans.Introspector

• Einfacher Fix:– Hashmap durch ConcurrentHashmap austauschen– im Benchmarkszenario 30% mehr parallele Requests erzielt (dann

war die CPU-Grenze erreicht - keine Lockcontention)

• Aber: SUN kann wegen Seiteneffekt keinen Fix im JDKakzeptieren– eingesetzte HashMap ist eine WeakHashMap die ein Caching

ermöglicht das von GC abgeräumt werden kann– ConcurrentHashMap zeigt anderes Speicherverhalten

• unproblematisch in unserem Fall da Caching klassenweit möglich ist

• Ausblick: Douglas Leas JSR 166x Package enthält möglicheLösung, die beide Spezifikationen erfüllt

48


Übersicht

Fazit

25

49


Persönliche Erfahrung führte zur ICW Gründung

„Es ist Samstagabend: die kleine Tochter von Peter Reuschel hatkrampfartige Hustenanfälle und bekommt kaum noch Luft. Derherbeigerufene Hausarzt kann zwar die akuten Symptome lindern,für eine genaue Diagnose braucht er aber eine Röntgenaufnahmeder Lunge. Das Bild wird in der Notfallambulanz der nächstenKlinik gemacht, doch die Eltern sollen nur einige handschriftlicheStichworte zum Befund mitbekommen. Die Eltern wollen abernicht, dass ihre Kleine nur anhand einiger schwer leserlicherNotizen weiterbehandelt wird, und bitten darum, das Röntgenbildfür den Hausarzt mitnehmen zu dürfen. Doch die Dienst habendeÄrztin antwortet nur, dass der Hausarzt das Bild bei Bedarfanfordern könne und es ihm dann in drei Wochen vorliege. Vonihren gesetzlichen Patientenrechten wissen die Eltern nochnichts.“

http://www.icw-global.com/de/de/unternehmen/gruendungsgeschichte.html


Screenshot of LifeSensor Fitness.

Links to calendar, medical data, emergency data, documents, personal data,news and account information.

Project: persönliche Gesundheitsakte “LifeSensor®”

• Herzstück der ICW Plattform istLifeSensor, eine patientengeführteGesundheitsakte, die derDatensammlung und-bereitstellung dient.

26

51


Integration: Personal Health Record Connected

• Ziel:IntegrationdesvollständigenmedizinischenInformations-flusses mitAnspruchsver-waltung undAbrechnung ineinerpatienten-orientiertenelektronischenAkte

• Ergebnis:Integration mitvielenSystemen undBeteiligten

LifeSensor® fosters platform approach

52


Siehe http://idn.icw-global.com/solutions/community/conferences/icw-developer-conference-may-2008/conference-proceedings.html

High system complexity

• System nutzt aktuelle Software Komponenten wie z.B:– JSF, Apache Tomcat, Axis, Apache httpd, Spring Framework

• läuft auf verschiedenen Web Browsern mit Html, CSS und Ajax• exponiert Web Services

27

53


Ergebnisse ICW Performance Lab bis August 2008

• Ende 2006 Benchmark eingeführt– Konzeption, Implementierung, Test, Übergabe

• Anzahl der parallelen Web GUI user in dieser Phase um Faktor 5erhöht

• Web GUI response time reduziert um 40%

• 2007 Test by SUN Microsystems in Langen– Anzahl der parallelen User noch einmal Faktor 3 erhöht– 6000 parallele User (Spitzenlast)

Quelle: http://www.icw-global.com/de/de/partner/benchmarks/benchmark-tests/lifesensor-with-hp.html

54


Ergebnisse ICW Performance Lab bis August 2008

• Test mit HP in Böblingen– 10 Millionen Akten (500 Akten pro Professional) ~ 1TB– 8500 (10 000) parallele Benutzer (Spitzen)last– Oracle Database 10gR2 Patch set 10.2.0.4 64bit– Tomcat 6.0.13 Cluster mit 6 Servern– Java 6 Update 6

28

55


Best Practices

• Definition einer klaren Statemanagement Strategy– z.B. Konversationskonzept

• Verwendung gut dokumentierter Lösungspatterns– Vermeidung von Standardfehlern– z.B. Datenvisualisierung

• AJAX-Integration– keine gegenläufigen Ansätze– Orientierung auf echte Usability– z.B. RichFaces vs. Dojo

56


Architektur

• Die JSF Architektur– hat viele „Stellschrauben“ in Bezug auf Performanzaspekte

• oft einfach durch reine Konfiguration• „saubere“ Programmierung vorausgesetzt

– Communities sorgen für Praxisnähe und -einsatz der Ideen

• Starke Architektur-Governance senkt QM-Kosten– z.B. Serializable Issues, ThreadLocal Leaks

29

57


Das letzte Wort

Leistungsgrenzen der Kombination– JSF– Integrationframework– OR-Mapper

sind am technologischen Gesamtstack aus– JVM– OS– RDBMS– Netzwerk– IO

angelehnt.




Vielen Dank für IhreAufmerksamkeit !

30




? ?

???

Fragen ?

60


Mehr von OIO zum Thema...

• Schulung: JavaServer Faces– http://www.oio.de/java-server-faces.htm

• Schulung: Systematisches Performance Tuning– http://www.oio.de/seminar/entscheider/performance-tuning-schulung.htm

• Beratung zur Performance Optimierung– http://www.oio.de/beratung-consulting/performance-optimierung/index.htm

• Vortrag: Love & Peace & JSF– http://www.oio.de/public/java/jsf-woodstock/JM1.09_Love_Peace_JSF.pdf

• Vortrag: JSF und AJAX– http://www.oio.de/m/konf/oop2007/OOP07_JSF-AJAX.pdf

leistungssport - oio · 1 orientation in objects gmbh weinheimer str. 68 68309 mannheim version:...

Documents