The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions.relied upon in making purchasing decisions.The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

BPEL Performance Tuning and Clustering Best Practises

Stefan Koser, Enterprise Architect DirectorORACLE Deutschland B.V. & Co. KG

Agenda

• Projektbeispiele BPEL

• Performance

• BPEL Tuningparameter

• BPEL Design – Best Practises/Antipattern

• DB Tuning für BPEL• DB Tuning für BPEL

• Performance Monitoring

• Clustering

• Projektergebnisse und Zusammenfassung

Real-world ExamplesReal-world Examples

Projekt 1CRM Integration with AIA 2.4 and BPEL 10.1.3.4• Kunde

– Europäischer Telekommunikationsprovider

• Integrationsszenario– Siebel CRM zu Backend Order Fulfillment Systemen

– Meist synchrone Intergrationsflows

– 1 Async. Flow (Fire & Forget) für Order Submit

• Produktstack– Siebel CRM 8.1– Siebel CRM 8.1

– AIA Foundation Pack 2.4 (AIA for Comms)

– Order to Cash Half-PIP

– Customer Data Hub Half-PIP

– Oracle SOA Suite 10.1.3.4 MLR#8

– Anforderungen: je nach Integration Flow in AIA – max. 0,1 bis 0,8 Sekunden Ausführungszeit

– 95 % aller Ausführungen in weniger als 0,2 bis 2,0 Sekunden

Projekt 1 – Typischer Integrationsfluss (synchron)Feasibility Check

BPEL ESBBPEL

ESB BPEL

Projekt 1 – Typischer Integrationsfluss (asynchron)Order Submission

BPELESB

BPEL

ESB

Projekt 2Order Fulfillment Telekommunikation• Kunde

– Europäischer Telekommunikationsprovider

• Integrationsszenario– Realisierung der Geschäftslogik für die Auftragsverarbeitung im Großkundenbereich

– Inkl. Anbindung von CRM, Billing, SAP, etc.

• Produktstack– Oracle SOA Suite 10.1.3.4 MLR#8– Oracle SOA Suite 10.1.3.4 MLR#8

– Oracle RAC

• Anforderungen– Durchsatz mind.12.000 Aufträge pro Tag (Business Hours, Phase 1)

– Enspricht ca. 1 Mio neue BPEL-Instanzen pro Tag

– Komplexe Geschäftlogik (Terminverschiebung, Stornierung, etc.)

– Großer Payload, langlaufende Prozessinstanzen

Projekt 2Langlaufende Prozessinstanzen

100000

1000000

10000000

100000000

Anzahl BPEL Instanzen in DB nach Execution Time

Count

1

10

100

1000

10000

1 6111621263136414651566166717681869196

101

106

111

116

121

126

131

136

141

146

151

156

161

166

171

176

181

BPEL Performance

Performance im SOA-Kontext

• Reliablibilty– End-to-End Transaktionalität (z.B. Kein Nachrichtenverlust)

– Recovery von Nachrichten

– Automatisches Transaction Recovery und Rollback (JTA, XA)

• Scalability– Vertikale vs. horizontale Skalierbarkeit – H/W, OS, JDK

– Sizing – DB, AQ, JMS, Messaging Infrastruktur, Middleware– Sizing – DB, AQ, JMS, Messaging Infrastruktur, Middleware

• Durchsatz– Transaktionen pro Sekunde (TPS)

– End-to-End Transaktionszeit

– Verarbeitete Nachrichten (Bsp. Aufträge) pro Zeiteinheit

– Durchsatz vs. Antwortzeit

Synchrone vs. asynchrone BPEL ProzesseThreads

Receive

4

Receive

4synchronerProzessaufruf

Caller Thread, e.g. Servlet

msg persisted (DB)

(2nd) callback msg

(1st) process hydration

Tuning der BPEL Service Engine Thread Pools für Invoker und Engine Threads basierend auf Lastanforderungen (Peak/Avg), Prozesstypen und Dehydration Points

Sync Process Async Process

De/hydration

e.g. Servlet

asynchronerProzessaufruf durch BPEL Engine invoker thread

Receive

4

Nach Hydration (e.g mid-process receive activity for async callback) wird der Prozess in einem Engine Thread ausgeführt

(2 ) callback msg persisted (DB), triggers dehydration

Reply

BPEL ExceptionsInvoke / Callback Message Recovery

Receive

4

Receive

4

Recovery von Invoke und Callback Nachrichten über die EM console – BPEL SE Recovery Webseite

msg persisted (DB)

(2nd) callback msg

(1st) process hydration

Sync Process Async Process

De/hydration

Receive

4

Exception oder System crash führt Rollback nach DB durch, verfügbar im EM für manuelles Recovery (Callback)

Exception oder System Crash

gibt Exception (oder Timeout)

zum Aufrufer zurück

Exception oder System crash führt Rollback nach DB durch, verfügbar im EM für manuelles Recovery (Invoke)

(2 ) callback msg persisted (DB), triggers dehydration

* – A 3rd type of recovery is Activity recovery.

Tuningparameter für synchrone Prozesse (1)

• inMemoryOptimization (default: false):– für nicht-persistente (d.h transiente) BPEL-Prozesse

– vermeidet jegliche Datenbankinteraktion, Verarbeitung vollständig im Hauptspeicher

– nur bei Prozessen ohne Aktivitäten wie z.B. wait, (mid-process) receive, onMessage oder onAlarm.

• completionPersistPolicy (default: on):• completionPersistPolicy (default: on):Dieses Property kontrolliert ob bzw. wie die Meta-Daten einer BPEL-Instanz gespreichert werden:

– on: die BPEL-Instanz wird normal in der Datenbank gespeichert

– deferred: die BPEL-Instanz wird in einem seperaten Thread (asynchron) in der Datenbank gespeichert

– faulted: nur fehlerhaft abgebrochene BPEL-Instanzen werden in der DB gespeichert

– off: keine BPEL-Instanz wird in der DB gespeichert

Tuningparameter für synchrone Prozesse (2)

• completionPersistLevel (default: all):Kontrolliert in Verbindung mit completionPersistPolicy, wieviel nach Beendigung eines transienten Prozesses gespeichert wird.

Wird nur benutzt, wenn inMemoryOptimization = true.

– all (default): Alle Instanzdaten werden gespeichert, inklusive finale Variablenwerte, Work Items und Auditdaten.

– instanceHeader: BPEL Process Manager speichert nur die Metadaten (Endezustand, Start- und Endezeiten, etc.)Metadaten (Endezustand, Start- und Endezeiten, etc.)

� Setzen auf “instanceHeader” kann I/O Durchsatz wesentlich verbessern und Datenwachstum in DB verringern.

Beispiel-Ergebnisse inMemoryOptimization(Projekt 1)

Medium Complex BPEL Process with 3 subprocesses - RMI calls (no soap)

Averageresponse time

Without optimization 60,26 ms

InMemoryOptimization=true 24,46 ms

+ completionPersistLevel=instanceHeader 21,58 ms

+ completionPersistPolicy=faulted 19,06 ms+ completionPersistPolicy=faulted 19,06 ms

+ statsLastN=0 18,31 ms

���� Verbesserung von 60 ms auf 18 ms

Tuningparameter für asynchrone Prozesse

• OneWayDeliveryPolicy (default: all):(in 10g: deliveryPersistPolicy)

Spezifiziert, wie One-Way Invoke Nachrichten verarbeitet werden

– async.persist(default): getrennter Thread, Speicherung in DB

– async.cache : getrennter Thread, In-Memory

– sync : gleicher Thread, dieselbeTransaktion

� Setzen auf “sync” kann DB-Performance verbessern.

Asynchrone Prozesse in BPELCallback Resolution

1. receiveCallbacka) Eintragen in DLV_MESSAGE Datenbanktabelle

b) State = 0 (=received/unresolved) setzen

2. resolveCallbacka) SOAPProtocolHandler nutzt Webservice Adressing

Informationen und CorrelationSets, um den Empfänger zu Informationen und CorrelationSets, um den Empfänger zu bestimmen.

b) State = 1 (=resolved) setzen

3. performCallbacka) Ausführen der Empfangsaktivität.

b) State = 2 (=handled) bzw. 3 (=cancelled) setzen

Warum sind Callbacks „teuer“?

• Exclusive Lock sind für das Ändern der Status der Callback-Nachrichten erforderlich

• Die Reihenfolge von Subscription und Callback-Nachricht kann beliebig sein – z.B. können Callback-Nachrichten eintreffen, bevor eine Subscription erzeugt wurde

• Komplexe SQL-Query notwendig für Bestimmung, ob eine • Komplexe SQL-Query notwendig für Bestimmung, ob eine Callback-Nachricht zu einer Subscription passt

Beispiel-Query

SELECT /*+ INDEX (ds1 ds_conversation, DS_FK) */

ds1.conv_id, ds1.conv_type, ds1.cikey,

ds1.domain_ref, ds1.process_id, ds1.revision_tag,

ds1.process_guid, ds1.operation_name, ds1.subscriber_id,ds1.service_name,

ds1.subscription_date, ds1.state, ds1.properties

FROM dlv_subscription ds1, (

SELECT DISTINCT /*+ INDEX (ds2 ds_conversation, DS_FK) */

ds2.cikey

FROM dlv_subscription ds2

WHERE ds2.conv_id = :1 AND ds2.state = 0 AND ds2.domain_ref= :2 ) WHERE ds2.conv_id = :1 AND ds2.state = 0 AND ds2.domain_ref= :2 )

unresolved_subscriptions

WHERE ds1.cikey = unresolved_subscriptions.cikey AND

ds1.state = 0 AND NOT EXISTS (

SELECT /*+ INDEX (ds3 ds_conversation, DS_FK)

INDEX (ds1 ds_conversation, DS_FK) */ 1

FROM dlv_subscription ds3

WHERE ds3.state = 1 AND ds3.cikey = ds1.cikey AND

ds3.domain_ref = ds1.domain_ref ) AND ds1.domain_ref = :3

FOR UPDATE OF ds1.subscriber_id NOWAIT

Mögliche Lösung: Alternatives MEP

• Zwei getrennte BPEL-Instanzen statt einer BPEL Prozessinstanz mit Invoke-Callback – 2 BPEL Prozesse

• Einer für Invoke-Aufruf

• Einer für Callback-Verarbeitung

– Callback-BPEL-Instanz wird immer neu gestartet – keine Correlation

– Beim Invoke Setzen der Callback-URL mit ReplyToAddress Property

– Keine Modifikation des aufgerufenen BPEL-Prozesses nötig

Calling Thread

Invoke

Receive

Callee Thread

Receive

Callback

Correlation

Calling Thread

Invoke

Callback Thread

Receive

Callee Thread

Receive

Callback

wsa:ReplyTo

Perfect 4Now lets Tune it for performance4

Performance Tuning – Übersicht

• BPEL/BPMN:

• Thread tuning

• Audit-Trail

• Dehydration

SOA Komponentenlevel

• OS

• JVM (insbesondere GC)

• Datenbank

• JDBC

Allgemein

• Audit Level

• Payload Validation

• Purging

• SOAP vs. RMI (local calls)

SOA Infrastruktur

• Message persistence

• Stats

• Mediator : Audit Level, Worker Threads

• Adapter: Threads, Batch size

• Weblogic Application Server

• 4. und Hardware!(Bsp. I/O Performance SAN, Network)

calls)

+ +

Performance Tuning – BPEL

BPEL/BPMN 11g Engine Level Properties

Performance Tuning – BPEL

BPEL Engine Level Properties

• # von Threads für “Invoke” Nachrichten (dspInvokeThreads)• # von Threads für “Engine” Nachrichten (dspEngineThreads)• # von Threads für Systemnachrichten (dspSystemThreads)

Concurrency

• Audit Trail Loglevel (AuditLevel)• Message Persistenz (oneWayDeliveryPolicy)Memory / DB

• XML Validierungen (validateXML)• Statistiken der letzten Prozessverarbeitungen (statsLastN)CPU

Performance Tuning – BPEL

BPEL 11g Process Level Properties

Performance Tuning - BPEL

BPEL Process Level Properties

• Parallele Verarbeitung von “Invoke” in mehreren Branches (nonBlockingInvoke)

• Synchrones / Transientes Prozessdesign

Response Time

• Wann wird Dehydration im Prozess benötigt? • Wann wird Dehydration im Prozess benötigt? (inMemoryOptimization)

• Speicherung von Instanzdaten (completionPersistPolicy)

Database

• Payload Validierung (validateXML)CPU

Performance Tuning – SOA Infrastructure

SOA 11g Infra Properties

CACA

Performance Tunings – SOA Infrastructure

• Audit Level• PurgingDatabase

SOA Infrastruktur

• Payload ValidationCPU

Performance Tuning – Allgemein

• Production Mode • Connection Pooling• Logging• Self tuning

Weblogic

• Heap Size• Nursery Size• GC Algorithm JVM • GC Algorithm • Use Large pages• 64 bit vs 32 bit

JVM

• SOA & Application Schema tuning • Tuning Parameters• Redo Logs

Database

BPEL 10g Examples

BPEL Thread Pool Tuning (10g)

Beispiel für eine gute Dimensionierung des Invoke Thread Pools

BPEL Thread Pool – Normale Callback-Last

BPEL Thread Pools – Ausgewogenes Sizing

BPEL Thread Pool – Überlast des Engine Pools

BPEL Thread Pool-Dimensionierung für Spitzenlast

Negativbeispiel: • Invoke Pool ist zu klein• Pending Time wird nur langsam abgebaut

Thread Pool Unterdimensionierung führt zu extremer Performanceverschlechterung

End of Test

Max. 80 Invoke Threads

Zu kleine Thread Pools:steigende Pending Time

Pending Time

End of Test

BPEL DesignBest Practises

Anti-Pattern 1 – “Programming” in BPEL

• Extensive Nutzung von Schleifen in BPEL– Iterationen über große Scopes / Variablen skaliert nicht mit großen Schleifenwerten

• Misbrauch von FlowN (Batch/event paradigm)– Sehr große Anzahl von FlowN –

bremst Server, führt zu hoher Threadzahl

– Problem von langlaufenden – Kann zu sehr großer JVM Heapnutzung und potenziellen GC Engpässen führen.

– Problem von langlaufenden Instanzen

• Übertreibung von Unterprozessschachtelung

Asynchrones vs. Synchrones Design

• (Über-)Nutzung asynchoner Prozesse für synchrone Szenarien (Mediator/BPEL)– Fügt Callback-Overhead hinzu

– Entwickler sind sich nicht der Transaktionsgrenzen bewusst

– Erhöhte Betriebsaufwände wg. Recovery von Callbacks

• (Über-)Nutzung von Callbacks in einem BPEL • (Über-)Nutzung von Callbacks in einem BPEL Prozess (“Chatty System”)– Jede Callback-Aktivität ist ein Dehydration Point der

komplexe DB-Aktivität erzeugt

– Zu viele Callback-Aktivitäten (bzw. Mid-Process Receive) können die Performance schnell beieinträchtigen

Anti-Pattern 3 – Large Payload und BPEL-Variablen

• Große Payloads werden mehrfach und über lange Prozesslaufzeiten in BPEL Variablen gespeichert.

• Variablen werden mehrfach zwischen verschiedenen Namespaces kopiert.

• Große Business Objects (EBO) werden immer komplett aus der DB geladen und speichert.komplett aus der DB geladen und speichert.

DB-Tuning für BPEL

Die Wichtigkeit von DB-Tuning für BPEL

• Kritischer Erfolgsfaktor bei persistenten Prozessen ist Datenbanktuning sowie Tuning von Datasource- und Connection-Pool-Konfiguration

• BPEL Console und Laufzeitengine können sich gegenseitig beeinflussengegenseitig beeinflussen

• Nutzung von Partitioning verbessert Performance bei sehr großen Datenmengen (ab 10.1.3.5 bzw. 11g PS3)

BPEL 10g Connection Pool Tuning

Purging und DB Retention Policies

• Nicht-optimiertes DB Purging– Hat meist größte Auswirkungen auf eine SOA Applikation

– Beeinflusst Performanz von Laufzeit SQL-Abfragen negativ

– Beeinflusst insbesondere asynchrone BPEL Prozesses

– Verlangsamt Zugriff auf BPEL-Console bei Abfrage von Audit Daten

– Sehr großer Overhead beim Purgen von Daten – Längere Zyklen erforderlich, Defragmentatierung der DB, Wartungsfenster

– Wenn Retentionperiod lang ist, wird größerer Diskspace wg. BLOB Spalten benötigt.

• Abhilfe:– Regelmäßiges Purge

– Frühzeitiges Purge

– Update des Skriptes über Metalink

– Verwendung CTAS Script (Downtime erforderlich) - Patch 9315108

Beispiel aus Projekt 2 Hohe Kosten für Purge in DB (ohne Optimierung)

Execution Plan

------------------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |

------------------------------------------------------------------------------------------------------------------

| 0 | INSERT STATEMENT | | | | | 16G(100)| |

| 1 | COUNT STOPKEY | | | | | | |

| 2 | HASH JOIN ANTI | | 21421 | 2656K| 2488K| 16G (1)|999:59:59 |

| 3 | TABLE ACCESS FULL | INVOKE_MESSAGE | 22675 | 2214K| | 371K (1)| 01:14:16 |

| 4 | VIEW | VW_SQ_1 | 17G| 447G| | 16G (1)|999:59:59 |

| 5 | TABLE ACCESS BY INDEX ROWID | DOCUMENT_DLV_MSG_REF | 13373 | 1149K| | 15623 (1)| 00:03:08 |

| 6 | NESTED LOOPS | | 17G| 2434G| | 16G (1)|999:59:59 |

| 7 | NESTED LOOPS | | 1329K| 74M| | 2336K (1)| 07:47:21 |

| 8 | TABLE ACCESS BY INDEX ROWID| CUBE_INSTANCE | 756K| 6650K| | 65572 (1)| 00:13:07 || 8 | TABLE ACCESS BY INDEX ROWID| CUBE_INSTANCE | 756K| 6650K| | 65572 (1)| 00:13:07 |

| 9 | INDEX RANGE SCAN | STATE_IND | 777K| | | 1655 (1)| 00:00:20 |

| 10 | INDEX RANGE SCAN | DOC_CI_REFERENCE_PK | 2 | 100 | | 3 (0)| 00:00:01 |

| 11 | INDEX RANGE SCAN | DDMR_DOCKEY | 16732 | | | 142 (0)| 00:00:02 |

------------------------------------------------------------------------------------------------------------------

Performance Monitoring

BPEL Thread Pool Monitoring (10g)

• BPEL Engine Statistiken sind in der BPEL Console und über BPEL Java API auswertbar

• Für die Länge der Invoke und Delivery-Queue wird keine Historie in der BPEL Console dargestellt – dies ist nur über das BPEL API möglich.

Monitoring über DMS Sensoren in EM 11g

• DMS Sensoren sind als MBeans verfügbar und im EM anzeigbar– Farm_soainfra > SOA > soa-infra > SOA Infrastructure > Administration > System MBean Browser

Viewing DMS Sensors in EM (cont’d)

Noun: bpel

Noun path: /soainfra/engines/message_processing/bpel

Sensor name:– activeRequests (state)

– faultPostProcessingTime (phase event)

MBean name: oracle.dms.Location=soa_server1,

name=/soainfra/engines/message_processing/bpel, type=soainfra_message_processing

– faultPostProcessingTime (phase event)

– faultRequestProcessingTime (phase event)

– postProcessingTime (phase event )

– requestProcessingTime (phase event)

BPEL JVM und GC Monitoring

• Thread Waits durch blockierte Resourcen identifizieren

• Häufigkeit von Full GCs verringern

• Bei großen Nachrichten und langlaufenden Prozessen ist der inkrementelle GC besser als AggressivGC geeignet

Clustering

SOA Suite 10g HA / Cluster-Konzept

Komponente Cluster Communication Technologie

BPEL, ESB and OWSMApplication Server Clusterware (OPMN) für dynamisches Routing mit OHS

BPEL Process Manager1. Database / Dehydration Store (ab 10.1.3.5)

2. jGroups (bis 10.1.3.4)BPEL Process Manager

2. jGroups (bis 10.1.3.4)

Enterprise Service Bus

1. AQ Messaging

2. jGroups (nur Singleton Adapter)

3. OPMN (active / passive design-time config)

BPEL 10g Cluster Konfiguration

• Jgroups bis 10.1.3.4

• Configuration in jgroups-protocol.xml

• 2 Varianten

• UDP (Multicast)

• TCP<config>

<TCP start_port="30200" loopback="true" send_buf_size="32000" recv_buf_size="64000"/>

<TCPPING timeout="3000" initial_hosts="10.151.129.12[30200],10.151.129.13[30200]"

port_range="2" num_initial_members="2"/>port_range="2" num_initial_members="2"/>

<FD timeout="10000" max_tries="5" shun="true" down_thread="false" up_thread="false"/>

<FD_SOCK down_thread="false" up_thread="false"/>

<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>

<pbcast.NAKACK gc_lag="100" retransmit_timeout="600,1200,2400,4800"/>

<pbcast.STABLE stability_delay="1000" desired_avg_gossip="20000" down_thread="false"

max_bytes="0" up_thread="false"/>

<VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />

<pbcast.GMS print_local_addr="true" join_timeout="5000" join_retry_timeout="2000" shun="true"/>

</config>

• DB-based from 10.1.3.5.1

• Update mit Patch 8608385

• Logger “collaxa.cube.cluster” für Debugging

BPEL 10g Clustering Best PractisesTCP statt UDP?

Nutzung von TCP statt UDP mit jGroups wenn– kein Multicast konfiguriert werden kann (z.B. aufgrund von Sicherheitsbeschränkungen).

– der BPEL Process Manager über verschiedene Subnets kommuniziert.

– eine größere Anzahl von Knoten im Cluster benutzt wird.– eine größere Anzahl von Knoten im Cluster benutzt wird.

– die Performance von UDP im Netzwerk langsam ist.

SOA 11g HA Architektur 2 Ebenen von Clustering

• WLS Cluster– Definiert in config.xml

– Kann über WLS Console und EM Console angezeigt werden

• SOA Cluster• SOA Cluster– Basiert auf Coherence

– Definiert über Systemparameter im Startup Script

– Kann über Deployment / Konfigurationsänderungen validiert werden.

Konfigurationsverteilung im Cluster

WLS Configuration• Datei-basiert

SOA Configuration• DB-basiert (MDS)

SOA 1

SOA 2

Admin MDS

WLS Konfiguration SOA Konfiguration

WLS + Coherence Clusters

• Datei-basiert

• AdminServer hat “gold” Kopie

• Konfiguration wird mit WLS JMX Framework propagiert

• Während Startup kopiert ein Managed Server die Konfiguration vom AdminServer und überschreibt die lokale Kopie.

• DB-basiert (MDS)

• Datenbank hat “gold” Kopie.

• Konfiguration wird propagiert von soa-infra mit Coherence Cluster.

• Während Startup lädt ein SOA Server seine Konfiguration aus MDS.

Cluster DeploymentAutomatische Propagierung nach Deployment

4

6

7

jDeveloper / command-line process deployment

1

2 soa-infra deploys compositesoa-infra persists composite archive into MDS

3

Coherence notification message of new

4

node2node1

soa_server2

DB

soa_server1

5 2

41

message of new deploymentsoa-infra server loads composite archive from MDS and deploys

5

Coherence notification message of successful deployment

6

If all deployments successful, broadcast “start” composite message, else issues “rollback”

7

3

* – A soa-infra start / re-start always synchronizes to the deployed composites defined in MDS

Zusammenfassung

Zusammenfassung – Ergebnisse Projekt 1

• Performance für AIA-only Execution Time– ReqABCS � EBS �EBF � EBS �ProvABCS

– BPEL � ESB �BPEL � ESB �BPEL

• 100% unter 0,4 s

• 95% unter 0,3 s

• Avg: 0,21 s

(z.Vgl.: ohne Tuning:

Avg: 0,62 s)

Zusammenfassung – Ausgangssituation Projekt 2

• Designprobleme– BPEL als Programmiersprache und für XML-Verarbeitung

– Zu viele asynchrone Unterprozesse in BPEL

• Laufzeitprobleme– schnelles Wachsum des DB-Volumens – schnelles Wachsum des DB-Volumens

� sinkende DB Performance

� sinkender Durchsatz BPEL

– Zu hohe Zeitdifferenz zwischen Updates über asynchrone BPEL-Sensoren und Verarbeitung in DB per PL/SQL

• Betriebsprobleme:– Zu später Einsatz von Purging

– Kein fachliches Bereinigen von „Missing Callbacks“

Zusammenfassung – Ergebnisse Projekt 2

– Ersetzung von XML-Verarbeitung in BPEL durch XSLT

– Eliminierung von Unterprozessebenen – Ersetzung durch Scopes

– Purging

• Vorher: 80.000 Instanzen: > 9 h

• Nach Optimierung: 1 Mio Instanzen in ~ 3 h

• CTAS Purge Skript: 2,2 Mio Instanzen in 3 h• CTAS Purge Skript: 2,2 Mio Instanzen in 3 h

– Umstellung von BPEL-Sensoren auf synchrone Invokes

– Umstellung von asynchronen Hilfsservices in BPEL auf synchrone in-Memory Services

– Lastbegrenzung am Eingang verhindert Überlast

– Dadurch Erreichung des geforderten Durchsatzes

Fazit – Key Success Factors BPEL Performance

• Verstehen der Anforderungen und Use Cases

• Wahl der geeigneten Message Exchange Pattern

• Wahl der richtigen Einsatzszenarien für BPEL

• Fokus auf DB-Tuning bei BPEL Design

• Frühzeitige Berücksichtigung von Performance-• Frühzeitige Berücksichtigung von Performance-Requirements und Best Practises

• Frühzeitige Performance- und Lasttests mit hohen Datenmengen

• Kontinuierliche Bereinigung des Dehydration Stores durch Purgen

Fragen