Skip Headers
Oracle® Fusion Middleware Performance and Tuning Guide
11g Release 1 (11.1.1)

Part Number E10108-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

21 Oracle Service Bus Performance Tuning

This chapter describes tips for tuning Oracle Service Bus performance. It contains the following sections:

21.1 About Oracle Service Bus

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 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 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 routing the response back to the client.

It is necessary, therefore, 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.

21.2 Basic Tuning Considerations

Depending on your OSB usage and performance issues, you may consider tuning the following:

21.2.1 JVM Memory Tuning

JVM parameters can have an impact on OSB performance. The two primary JVM tuning parameters to consider when optimizing OSB performance are heap size and garbage collection. For more information on tuning the JVM for performance, see Section 2.4, "Tuning Java Virtual Machines (JVMs)".

21.2.2 WebLogic Server Tuning

To optimize OSB, consider tuning the following WebLogic Server parameters:

21.2.2.1 Domain Mode

For production environments, create a domain in "Production" mode to maximize performance. The parameter is:

-Dweblogic.ProductionModeEnabled=true

To enable Weblogic server production mode through Weblogic Administration Console, see Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server.

21.2.2.2 WebLogic Server Logging Levels

For OSB performance testing and production environments, consider using the lowest acceptable logging level, such as "ERROR" or "WARNING" whenever possible. For more information, see Section 2.10, "Setting Logging Levels"

21.2.2.3 HTTP Access Logging

To optimize OSB perfomance, consider turning off the HTTP access logging. For more information, see Section 5.3.1, "Access Logging".

21.2.2.4 JMS Tuning

Ensure that the right persistence level is set for the Java Message Service (JMS) destinations. Consider the following scenarios:

  • For non-persistent JMS scenarios:

    Explicitly turn off persistence at the JMS server level by un-checking the "Store Enabled" flag from the Advanced section of the General tab for the JMS server on the WebLogic Server console. It is also possible to override the persistence mode at the JMS destination level.

  • For persistent JMS scenarios:

    There are two choices: file store and JDBC store. Typically operations on a File Store perform better than JDBC store. If there are multiple JMS servers involved, create each store on a separate disk to lower I/O contention.

For more information on JMS Server Tunings, see "Tuning WebLogic JMS" in the Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.

21.2.2.5 Connection Backlog Buffering

You can tune the number of connection requests that a WebLogic Server instance will accept before refusing additional requests. The Accept Backlog parameter specifies how many Transmission Control Protocol (TCP) connections can be buffered in a wait queue. This fixed-size queue is populated with requests for connections that the TCP stack has received, but the application has not accepted yet. This parameter should be tuned when dealing a large number of concurrent clients. For more information, see "Tuning Connection Backlog Buffering" in Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.

21.3 Tuning OSB Operational Settings

This section discusses the following Oracle Service Bus operational settings:

21.3.1 OSB Monitoring

Though the out-of-the-box monitoring sub-system has a very low overhead and scales well to a large number of services as well as to multiple nodes in a cluster, when dealing with thousands of services or a large scale cluster deployment, being selective about enabling monitoring can help reduce network traffic. When a business or proxy service is created, monitoring is disabled by default for that particular service. For more information, see "Configuring Operational Settings for Proxy Services" or "Configuring Operational Settings for Business Services" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

To enable or disable monitoring of all services that have individually been enabled or disabled for monitoring, use the "Enable Monitoring" option on the Operations Global Settings page. For more information, see "Enabling Global Settings" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

21.3.2 OSB Tracing

Oracle Service Bus has the option to trace messages without having to shutdown the server. 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.

Tracing is disabled by default but can be enabled on a per service basis. When tracing is enabled, the entire message context is also printed including headers and message body. It is important to realize its impact for large message sizes and high throughput scenarios.

For more information, see "How to Enable or Disable Tracing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

21.3.3 Cache Tuning for Proxy Service Run-Time Data

OSB caches proxy service runtime meta-data using a two-level cache with static and dynamic sections. The cache introduces a performance tradeoff between memory consumption and compilation cost. Note that caching proxy services may help throughput but could impact memory usage.

The static section is an upper-bound Least Recently Used (LRU) cache that is never garbage collected. When a proxy service is bumped from the static section, it is demoted to the dynamic section where the cache can be garbage collected when there is memory pressure.

The number of proxy services in the static portion of the cache can be tuned by setting its size using the system property com.bea.wli.sb.pipeline.RouterRuntimeCache.size. The default value is 100. This can be increased to a desired value provided there is sufficient memory for runtime data processing for large number of proxy services.

This property value can be set in the setDomainEnv.sh file as an extra java argument as follows:

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}

Example:

EXTRA_JAVA_PROPERTIES="-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000 ${EXTRA_JAVA_PROPERTIES}"

21.4 Transport Tuning (Oracle WebLogic Server and Oracle Service Bus)

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:

21.4.1 Polling Interval

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:

21.4.2 Read Limit

The read limit determines the number of files or messages that are read per polling sweep. This defaults to 10 for the File and FTP transports. It can be set to 0 to specify no limit. Set this value to the desired concurrency. For more information, see " File Transport Configuration Page" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Note:

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 OOM (out-of-memory error) if the message size is large.

21.5 Design Time Considerations for Proxy Applications

Consider the following design configurations for proxy applications based on your OSB usage and use case scenarios:

21.6 Design Considerations for XQuery Tuning

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>