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