About Oracle Business Activity Monitoring About Oracle User Messaging Services

19-2 Oracle Fusion Middleware Performance and Tuning Guide acknowledgment. Without windowing i.e., a WindowSize of 1, the driver must wait for a synchronous acknowledgment from the SMSC before sending the next message. With windowing, more messages can be sent per network round-trip, allowing a higher overall throughput. To take advantage of an increased WindowSize, the number of MDB threads for the driver must be correspondingly increased. The two values should be matched so that driver threads can process and send messages before waiting for the requests to be acknowledged. Increasing the two values may improve performance, but only up to the point at which network latency no longer dominates the sending rate. Also, the maximum allowed value for the WindowSize is normally defined as a service policy by the SMSC operator. For more information, see Configuring Oracle User Messaging Service in Oracle WebLogic Communication Services Administrators Guide.

19.2.2 Email Driver Polling Frequency

For Email drivers, the CheckMailFreq configuration parameter defines how frequently the driver checks for incoming emails. For example, a value of 30 means the driver checks the configured inbox every 30 seconds. This parameter can influence performance; checking more frequently enables the driver to keep up with a higher incoming email load, but can impact performance due to frequent IMAP or POP3 operations. Default value is 30 seconds.

19.3 Database Tuning for Optimal Throughput

User Messaging Service stores messaging state such as sent and received messages and delivery status information in the database. Therefore, database and data source tuning may have an effect on messaging throughput. The connection pool size for the data sources can be tuned for higher load levels, but the defaults are sufficient for most cases. For general database tuning considerations, see Section 2.6, Tune Database Parameters . 20 Oracle B2B Performance Tuning 20-1 20 Oracle B2B Performance Tuning This chapter describes tips for tuning Oracle B2B performance. It contains the following sections: ■ Section 20.1, About Oracle B2B ■ Section 20.3, Number of Threads ■ Section 20.4, JMS Multiple Out Queues Setting

20.1 About Oracle B2B

Oracle B2B is an e-commerce gateway that enables the secure and reliable exchange of business documents between an enterprise and its trading partners. Oracle B2B supports business-to-business document standards, security, transports, messaging services, and trading partner management. With Oracle B2B used as a binding component within an Oracle SOA Suite composite application, end-to-end business processes can be implemented. For more information about Oracle SOA Suite, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

20.2 MDS Cache Size

Changing the value of the Metadata Service MDS instance cache size can improve performance. A ratio of 5:1 is recommended for the xmx-to-mdsCache values. For example, if the xmx size is 1024, maintain mdsCache at 200 MB. These settings can be modified using Oracle Enterprise Manager Fusion Middleware Control. For more information, see Configuring Oracle B2B in the Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite.

20.3 Number of Threads

Changing the value of b2b.inboundThreadCount and b2b.outboundThreadCount can improve Oracle B2B message processing. The recommended value depends on your system. For a 2 GB computer, for example, a setting of 3 to 5 is recommended. The b2b.inboundThreadSleepTime and b2b.outboundThreadSleepTime properties put a thread to sleep after message processing. A setting between 10 and 1000 milliseconds is recommended. These settings can be modified using Oracle Enterprise Manager Fusion Middleware Control. For more information, see Configuring Oracle B2B in the Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite. 20-2 Oracle Fusion Middleware Performance and Tuning Guide

20.4 JMS Multiple Out Queues Setting

The JMS Out Queue component is the element that enables a client application to receive data from a JMS queue. To maximize performance, consider setting the Multiple JMS OUTQUEUES to 6. 21 Oracle Service Bus Performance Tuning 21-1 21 Oracle Service Bus Performance Tuning This chapter describes tips for tuning Oracle Service Bus performance. It contains the following sections: ■ Section 21.1, About Oracle Service Bus ■ Section 21.2, Basic Tuning Considerations ■ Section 21.3, Tuning OSB Operational Settings ■ Section 21.4, Transport Tuning WLS and OSB ■ Section 21.5, Design Time Considerations for Proxy Applications ■ Section 21.6, Design Considerations for XQuery Tuning

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 Administrators Guide for Oracle Service Bus.

21.2 Basic Tuning Considerations

Depending on your OSB usage and performance issues, you may consider tuning the following: ■ JVM Memory Tuning 21-2 Oracle Fusion Middleware Performance and Tuning Guide ■ WebLogic Server Tuning

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, Tune 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, Set 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 IO 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