This chapter describes tips for tuning Oracle Service Bus performance.
It contains the following sections:
Within a SOA framework, Oracle Service Bus (OSB) provides connectivity, routing, mediation, management and also some process orchestration capabilities. The design philosophy for OSB is to be a high performance and stateless (non-persistent state) intermediary between two or more applications. However, given the diversity in scale and functionality of SOA implementations, OSB applications are subject to a large variety of usage patterns, message sizes and QOS requirements.
In most SOA deployments, OSB is part of a larger system where it plays the role of an intermediary between two or more applications (servers). A typical OSB configuration involves a client invoking an OSB Proxy Service which may make one or more service callouts to intermediate back-end services and then route the request to the destination back end system before responding to the client.
It is necessary to understand that OSB is part of a larger system and the objective of tuning is the optimization of the overall system performance. This involves not only tuning OSB as a standalone application, but also using OSB to implement flow-control patterns such as throttling, request-buffering, caching, prioritization and parallelism.
For more information about Oracle Service Bus, see the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Oracle Service Bus performance largely depends on the performance of the other components. The following components affect OSB performance:
WebLogic Server
Coherence
Adapters
You can begin tuning Oracle Service Bus if you believe the above components are tuned to your satisfaction.
Starting in 12c (12.2.1), Oracle Service Bus can be tuned by several Oracle WebLogic Server Work Managers.
For example, Split-Join tuning can be accomplished using Work Managers. By default, applications do not specify a Work Manager for Split-Joins, but Split-Joins can be assigned a Work Manager if there are strict thread constraints that need to be met, such as scheduling parallel tasks.
For optimal performance, strike a balance between the following Work Manager constraints:
min-threads-constraint so that Split-Join operations are not starved of threads.
max-threads-constraint so that Split-Joins do not starve other resources
By default, there is no minimum or maximum thread constraint defined, which could either slow Split-Join operations down or slow down other operations sharing the same thread pool.
Work Managers will take Split-Join operations into account when allotting threads to system-wide processes so that this balance is met automatically.
For more information on tuning OSB with Work Managers, see "Using Work Managers with Oracle Service Bus" in Developing Services with Oracle Service Bus.
Table 19-1 lists and describes the knobs you will most likely need to tune to improve performance. For more information on monitoring Oracle Service Bus to diagnose trouble areas, see "Monitoring Oracle Service Bus" in Administering Oracle Service Bus.
Table 19-1 Essential OSB Operation Tuning
| Parameter | Problem | Tuning Recommendation | Trade-offs |
|---|---|---|---|
|
Monitoring and Alerting Default: |
The Monitoring and Alerting framework is designed to have minimal impact on performance, but all of these processes have performance impacts. In general, the more monitoring rules and pipeline actions you have defined, the larger the performance impact. |
Keep the default of The settings for monitoring and alerting can be configured in the Enterprise Manager Administrator Console. Note that monitoring must be enabled for SLA alerts but not for Pipeline alerts. |
Disabling these processes to improve performance means you will be sacrificing certain metrics and alerts that could help you troubleshoot issues in the future. For more information on the OSB Monitoring Framework, see "Introduction to the Oracle Service Bus Monitoring Framework" in Administering Oracle Service Bus. |
|
Tracing Default: Disabled |
If you have large message sizes and high throughput scenarios, tracing may be slowing your system down. |
Leave tracing disabled to improve performance. For more information, see "How to Enable or Disable Tracing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. |
If disabled, you will lose metrics. Tracing prints the entire message context, including headers and message body. This is an extremely useful feature both in a development and production environment for debugging, diagnosing and troubleshooting problems involving message flows in one or more proxy services. |
com.bea.wli.sb.pipeline. RouterRuntimeCache.size Default: 100 |
You may have one of the following issues: Proxy services are accessed slowly.This means you want to store more proxy services in the static portion of the OSB cache for pipeline service runtime meta-data. The proxy services stored here are never garbage-collected, meaning they are accessed faster. OR You are seeing a lot of cache misses in DMS dumps. |
If you want to include more proxy services in the static cache, increase this value as long as there is sufficient memory for runtime data processing for large number of proxy services. If you are seeing cache misses in DMS dumps, decrease this value. This system property caps the number of proxy services in the static portion of the OSB cache for pipeline service runtime meta-data. These services never get garbage collected. You set the size of this value in the setDomainEnv.sh file as an extra java argument, as follows:
-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}
For example, if you want to set this value to 3000, you would write:
EXTRA_JAVA_PROPERTIES=
"-Dcom.bea.wli.sb.pipeline.
RouterRuntimeCache.size=3000
${EXTRA_JAVA_PROPERTIES}"
|
Increasing this value decreases the time it takes to make initial calls to the proxy server. It can also preload the cache when a configuration session is committed. However, while caching proxy services helps reduce compilation costs, it also increases memory consumption. Decreasing this value may means you will free up memory, but making initial calls to the proxy server may take longer. |
|
Default: False |
JSON input to REST service may not be ordered as expected by the schema definition. When converting from JSON to XML, OSB runtime uses the order in which JSON name/value appear to construct the corresponding XML element. While well-formed, this format is not valid according to XML schema. |
Set this parameter to Checking this option will makes the REST service reorder the input JSON so that the response from the external REST endpoint can be ordered as per the valid schema definition. |
Using this option adds significant performance overhead. |
After you have performed the modifications recommended in the previous section, you can make additional changes that are specific to your deployment. Consider carefully whether the recommendations in this section are appropriate for your environment.
This section contains the following:
A Resequencer is used to rearrange a stream of related but out-of-sequence messages back into order. It sequences the incoming messages that arrive in a random order and then sends them to the target services in an orderly manner.
You can fine-tune the Resequencer by setting the properties listed in Table 19-2 using the Global operational settings page in the OSB EM console:
Table 19-2 Essential Resequencer Tuning
| Parameter | Problem | Tuning Recommendation | Trade-offs |
|---|---|---|---|
|
ResequencerMaxGroupsLocked Default: 4 groups |
This parameter defines the maximum number of message groups that can be locked by resequencer locker threads for parallel processing. The locked groups can then use worker threads to process their respective messages. If message processing is being delayed, identify which of the following situations is true:
|
Increase this parameter's value if you have many groups with a small number of messages each. Resequencer will lock more groups in one iteration. Decrease this value if you have a few groups with many messages. Resequencer will lock less number of groups for processing. |
Increasing the Decreasing the default value may result in under utilization of resources. |
|
ResequencerLockerThreadSleep Default: 10 seconds |
The resequencer locker thread queries the database to lock groups for parallel processing. When no groups are available, the locker thread "sleeps" for the configured amount of time specified by this parameter. This parameter needs tuning if you have either of the following situations:
|
Decrease this parameter value if you have a high number of messages to reduce the lag time during processing. Increase this value if Resequencer locker threads are making frequent database round trips even though you do not have many incoming messages. |
If the sleep time is too short, there may not be enough worker threads available to process incoming messages of the locked groups. Too many database queries will also cause slow performance. If the time interval between incoming messages is already long, configuring a higher value is not beneficial. |
|
DeleteMessageAfterComplete Default: |
The resequencer database is low on space. If you changed this parameter's value to false, processed messages remain in the resequencer database and slow down database inquiries. |
Keep the default value of |
You will not have a detailed history of processed messages. |
Consider the design configurations described in Table 19-3 for proxy applications based on your OSB usage and use case scenarios:
Table 19-3 Tuning Design Time for Proxy Application
| Strategy | Description | Recommendations |
|---|---|---|
|
Avoid creating many OSB context variables that are used just once within another XQuery |
Context variables created using an Assign action are converted to XmlBeans and then reverted to the native XQuery format for the next XQuery. Multiple "Assign" actions can be collapsed into a single Assign action using a FLWOR expression. Intermediate values can be created using "let" statements. |
Avoiding redundant context variable creation eliminates overheads associated with internal data format conversions. This benefit has to be balanced against visibility of the code and reuse of the variables. |
|
Transform contents of a context variable such as |
Transforming the contents of a context variable could be time-consuming. |
Use a Replace action to complete the transformation in a single step. If the entire content of $body is to be replaced, leave the XPath field blank and select "Replace node contents". This is faster than pointing to the child node of $body (e.g. $body/Order) and selecting "Replace entire node". Leaving the XPath field blank eliminates an extra XQuery evaluation. |
|
Specify a special XPath. |
A general XPath like " |
Use This is faster than specifying an absolute path pointing to the child of |
|
Enable Streaming for pure Content-Based Routing scenarios. |
OSB leverages the partial parsing capabilities of the XQuery engine when streaming is used in conjunction with indexed XPaths. Thus, See Section 19.3.3, "Tuning XQuery" for additional details. |
Enabling streaming means that the payload is parsed and processed only to the field referred to in the XPath. Streaming also eliminates the overhead associated with parsing and serialization of XmlBeans. Trade-offs: The gains from streaming can be negated if the payload is accessed a large number of times for reading multiple fields. If all fields read are located in a single subsection of the XML document, a hybrid approach provides the best performance. The output of a transformation is stored in a compressed buffer format either in memory or on disk. Therefore, streaming should be avoided when running out of memory is not a concern. |
|
Set the appropriate QOS level and transaction settings. |
OSB can invoke a back end HTTP service asynchronously if the QOS is "Best- Effort". Asynchronous invocation allows OSB to scale better with long running back-end services. It also allows Publish over HTTP to be truly fire-and-forget. |
Do not set XA or Exactly-Once unless the reliability level required is once and only once and its possible to use the setting (it is not possible if the client is a HTTP client). If OSB initiates a transaction, it is possible to replace XA with LLR to achieve the same level of reliability. |
|
Disable or delete all log actions. |
Log actions add an I/O overhead. Logging also involves an XQuery evaluation which can be expensive. Writing to a single device (resource or directory) can also result in lock contentions. |
Disable or delete all log actions. |
OSB uses XQuery and XPath extensively for various actions like Assign, Replace, and Routing Table. The following XML structure ($body) is used to explain XQuery and XPath tuning concepts:
<soap-env:Body> <Order> <CtrlArea> <CustName>Mary</CustName> </CtrlArea> <ItemList> <Item name="ACE_Car" >20000 </Item> <Item name=" Ext_Warranty" >1500</Item> …. a large number of items </ItemList> <Summary> <Total>70000</Total> <Status>Shipped</Status> <Shipping>My Shipping Firm </Shipping> </Summary> </Order> </soap-env:Body>
You can use the tuning strategies listed in Table 19-4 to tune XQuery.
Table 19-4 XQuery Tuning Strategies
| Strategy | Description | Recommendation |
|---|---|---|
|
Avoid the use of double front slashes ("//") in XPaths. |
"//" implies all occurrences of a node irrespective of the location in an XML tree. Thus, the entire depth and breadth of the XML tree has to be searched for the pattern specified after a "//". |
Use "//" only if the exact location of a node is not known at design time. |
|
Index XPaths when applicable. |
Indexing helps your system process only what is needed. When indexing, only the top part of the document will be processed by the XQuery engine. |
Index an XPath by adding "[1]" after each node of the path. For example, the XPath But if you know that there is a single instance of Note: Do not index when you need a whole array of nodes returned. Indexing will only return the first item node of the array. |
|
Extract frequently used parts of a large XML document as intermediate variables within a FLWOR expression |
An intermediate variable can be used to store the common context for multiple values. |
Using intermediate variables consumes more memory but reduces redundant XPath processing. |
|
Use a Hybrid Approach for read-only scenarios with Streaming |
The gains from streaming can be negated if the payload is accessed a large number of times for reading multiple fields. If all fields read are located in a single subsection of the XML document, a hybrid approach provides the best performance. |
Enable streaming at the proxy level and Assigning the relevant subsection to a context variable. The individual fields can then be accessed from this context variable. The fields "Total" and "Status" can be retrieved using three Assign "$body/Order[1]/Summary[1]" to "foo" Assign "$foo/Total" to "total" Assign "$foo/Status" to "total" |
Note:
Pipelines enabled for content streaming should use "XQuery 1.0". Using "XQuery 2004" does work, but incurs significant performance overhead, as there are "on-the-fly" conversions that happen to and from XQuery 1.0 engine. There is a design-time warning to that effect.Latency and throughput of poller-based transports depends on the frequency with which a source is polled and the number of files and messages read per polling sweep.
The following are the main transport configurations to tune:
Consider using a smaller polling interval for high throughput scenarios where the message size is not very large and the CPU is not saturated. The primary polling interval defaults are listed below with links to additional information:
| Polling Intervals | Default Interval | Additional Information |
|---|---|---|
| File Transport | 60 seconds | "File Transport Configuration Page" in the Developing Services with Oracle Service Bus |
| FTP Transports | 60 seconds | "FTP Transport Configuration Page" in the Developing Services with Oracle Service Bus |
| MQ Transport | 1000 milliseconds | "MQ Transport Configuration Page" in the Developing Services with Oracle Service Bus |
| SFTP Transport | 60 seconds | "SFTP Transport Configuration Page" in the Developing Services with Oracle Service Bus |
| JCA Transport | 60 seconds | "JCA Transport Configuration Page" in the Developing Services with Oracle Service Bus |
The read limit determines the number of files or messages that are read per polling sweep. You can tune it with the information in Table 19-5.
For more information, see "Using the File Transport" in Developing Services with Oracle Service Bus.
Table 19-5 Essential Read Limit Tuning
| Parameter | Symptoms if not properly tuned | Tuning Recommendation | Performance Trade-offs |
|---|---|---|---|
|
Read Limit Default: 10 for File and FTP transports |
Excessive memory use or high memory use due to a large number of files read into memory simultaneously. |
Set this value to the desired concurrency. It can be set to 0 to specify no limit. The read limit determines the number of files or messages that are read per polling sweep. |
Setting the Read Limit to a high value and the Polling Interval to a small value may result in a large number of messages being simultaneously read into memory. This can lead to an out-of-memory error if the message size is large. |