Say you have a simple BPEL process that gets messages from a JMS queue through a JMSAdapter, transforms the message, and then calls a down stream service via SOAP. For such a simple BPEL process, are there any optimizations that can be made to improve performance? The answer is "yes". We can gain some performance by understanding what is happening in the software layers between the inbound JMSAdapter and BPEL process.
Open up the WSDL file of the inbound adapter. You will notice something like the following:
Notice there is only an INPUT tag but no OUTPUT
One-way message is one of the interaction patterns between the caller and the BPEL process that Oracle BPEL supports.
By default, incoming one-way messages are saved in the delivery service database table
dlv_message (the invoke_message table in 10G). These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process. Such two-phase interaction can be illustrated as follows:
Separating message sending and message processing, and saving messages to the database make sense for a lot of cases. The biggest benefit is that this allows the sender of message to "fire and forget" - swiftly send the message and get done with it, even though the actual processing of the message make take a much longer time. One-way interaction is like email: with one click of the button you send an email and it's gone, while it may make take the recipient of the email 1 hour to read and act on it.
The other benefit is message reliability: Even if the SOA server is down before processing the message, the sender can rest assured that the message is reliably saved to the database so that it can still be processed once the server is up again.
But the same benefits may not make sense for an inbound JMSAdapter.
First the adapter probably doesn't care about fire and forget. What does matter is usually the overall speed or throughput of send+process, instead of just "send".
Second, the message was already saved to the inbound message queue before being picked up. It does not need to be saved at another place for the sake of reliability.
While the benefits of having separate threads to send and process the message
If we combine the two threads, and disable the insert into the database table, load against the database is reduced, latency of the insert will be eliminated, and the extra work the container was doing to manage it is avoided. Skipping this database insert can lead to improved response times.
It takes two steps to achieve the improvement and these steps must be done in tandem.
In SOA 10.1.3.x, you can set the deliveryPersistPolicy=off.immediate in the bpel.xml of the BPEL process in question.
For details of how the oneWayDeliveryPolicy works, please refer to the 13 Oracle BPEL Process Manager Performance Tuning of the Oracle® Fusion Middleware Performance and Tuning Guide. The 10G equivalent is http://docs.oracle.com/cd/B32110_01/core.1013/b28942/tuning_bpel.htm
For details of how to set this property in 11G, please refer to Appendix C Deployment Descriptor Properties of Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite. For 10G, please refer to Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0)
Now you have done step 1 to skip saving the one-way message to database. But just by looking at the picture above you may already notice there is a problem.
By not saving one-way messages to database table, the adapter threads become the major factor in terms of concurrency. The famous BPEL Invoke threads and engine threads no longer apply. This essentially means the application becomes single threaded, and therefor throughput may drop.
That is is why setting deliveryPersistPolicy=off.immeidate (in 10G) or oneWayDeliveryPolicy=sync (11G) should be done in tandem with increasing the number of adapter threads. Otherwise, you will likely create a drop in throughput. Optimal values of adapter threads should be determined through performance testing.
For JMSAdapter in 11G, you can set the adapter threads in the the properties for tuning the thread counts of various adapters are listed as follows.
For 10G BPEL, you set the JMSAdapter receiver threads at bple.xml of BPEL:
For 10G ESB, you set the JMSAdapter receiver threads at *esbsvc file of OESB:
After setting the oneWayDeliveryPolicy=sync (or deliveryPersistPolicy=off.immediate for 10G) AND configuring multiple threads, you can achieve shorter latency and higher throughput.
But besides the gain in performance, you can also enjoy the following side benefits:
When oneWayDeliveryPolicy=async, two layers control the incoming rate of messages into BPEL service engine: the adapter threads AND the BPEL invoke threads (see Figure 1 above). And because Invoke Threads are shared among BPEL processes running on the same JVM, you can't just throttle for one process without affecting another.
By setting adapter threads along with oneWayDeliveryPolicy=sync, you only need to throttle the incoming load with adapter threads, which only affects the SOA component that the adapter calls. You can throttle per adapter individually.
If there is an outage of SOA servers and the adapter stops dequeuing from the inbound message queue, the enterprise application on the other side of the queue may continue to enqueue. That builds up a large backlog in the inbound message queue.
By the time the SOA servers are restarted, with oneWayDeliveryPolicy=async, the large back log of messages in the queue may flood in the SOA servers, saturating all the Invoke Threads and leave no Invoke Threads available to handle other BPEL processes. In contrast, there is no such worry if you throttle the incoming loads to the BPEL process by setting oneWayDeliveryPolicy=sync along with adapter threads.
Rather than checking both the inbound message queue AND the dlv_message/invoke_message table at the database for the flow rate of messages into the BPEL service engine, you only need to monitor one place: the inbound message queue.