The following sections provides tips about designing and tuning high-performance Oracle WebLogic Integration applications. It contains the following topics:
This section provides the following design time performance tips:
By default, the branches of a parallel node are transactionally isolated. To improve performance, you can override this behavior by setting the continueTransaction
property in the source for each parallel element as follows:
<parallel continueTransaction="true">
Timer messages (messages set with a delivery time in the future) show up as “pending messages” in the Oracle WebLogic Server console.
For stateful processes, turn off maximum conversation lifetime if you are not using it:
For more information on the conversation lifetime feature, see “@jws:conversation-lifetime Annotation” in Java Web Service Annotations in Oracle WebLogic Web Services Reference.
The default timeout period for a transaction is 300 seconds (5 minutes). You can increase the amount of elapsed time before a transaction times out by using one of the following approaches:
transaction-timeout
element of wlw-config.xml.
This will change the timeout period for all transactions in your application..trans-timeout-seconds
value for the AsyncDispatcher MDB in weblogic-ejb-jar.xml
. This will change the timeout period for transactions processed by the AsyncDispatcher MDB only. For more information, see “trans-timeout-seconds” in “weblogic-ejb-jar.xml in WebLogic Server” in the
weblogic-ejb-jar.xml Deployment Descriptor Reference in Programming Oracle WebLogic Enterprise JavaBeans. For recovery considerations regarding transaction timeout periods, see Configuring Oracle WebLogic Integration Application for Recovery.
This section provides run-time tuning tips:
For optimum performance, use the following flags when starting Oracle WebLogic Server:
production noiterativedev nodebug notestconsole
Note: | These flags should be set by default when using a generated production domain, but not when using a development domain. |
Oracle WebLogic Integration projects map onto J2EE resources. The primary EJB pools you can tune within a Oracle WebLogic Integration project are the project beans: the SyncDispatcher
Stateless Session Bean (SLSB) pool and the AsyncDispatcher
Message-Driven Bean (MDB) pool. These pools exist for every Oracle WebLogic Integration project in an application.
All synchronous requests are routed through the SyncDispatcher
; all asynchronous (buffered) communication is routed through the AsyncDispatcher
.
There are two ways to configure the pool size of these beans:
weblogic-ejb-jar.xml
file to contain a dispatch-policy
element with the name of the thread pool to use. For more information, see “dispatch-policy” in “weblogic-ejb-jar.xml Elements” in the weblogic-ejb-jar.xml Deployment Descriptor Reference in Programming Oracle WebLogic Enterprise JavaBeans.
max-beans-in-free-pool
for the project beans. For more information about configuring MDB pool size, see “Setting Performance-Related weblogic-ejb-jar.xml Parameters” in Tuning Oracle WebLogic Server EJBs in Oracle WebLogic Server Performance and Tuning.
For background information on tuning in general, see Oracle WebLogic Server Performance and Tuning.
Yes. The JMS event generator by default has max-beans-in-free-pool
set to 5
. You can often set this value higher and improve performance.
For more information, see “Setting Performance-Related weblogic-ejb-jar.xml Parameters” in Tuning Oracle WebLogic Server EJBs in Oracle WebLogic Server Performance and Tuning.
If you ever plan to use versioning with a long-running business process, version your process from the beginning before deploying your application in production mode. Otherwise, you must let non-versioned instances run to completion before deploying the new versioned process.
For more information, see “Managing Process Versions” in Process Configuration in Managing Oracle WebLogic Integration Solutions.
Minimize process tracking levels as much as possible to optimize performance. Set tracking to none
as the default, and track selected JPDs as needed.
For information on how to configure tracking levels, see “Managing Process Tracking Data” in “About Process Configuration” in Process Configuration in Managing Oracle WebLogic Integration Solutions.
Yes. You should run the archiver process during non-peak hours to clean the process monitor table for stateful processes.
For information on how to configure the archiver process, see “Managing Process Tracking Data” in Process Configuration in Managing Oracle WebLogic Integration Solutions.
Edit <domain-home>/apacheLog4jCfg.xml
and change all occurrences of info
to warn
.
Each application will have a different threshold for the size of documents it is more efficient to pass by reference (using the document store) rather than inline. In general, the more trips a document makes, the better it is to use the document store. You configure the size of files passed by reference by setting the value of the weblogic.wli.DocumentMaxInlineSize
parameter in the Oracle WebLogic Integration application domain's wli-config.properties
file.
Note: | When using the document store, a two-phase commit related race condition in some cases may cause the following message to appear in the log: SQLException in retrievData() . In this situation, you can set the value of weblogic.wli.DocumentMaxInlineSize to a large number so that all documents will be passed inline. |
If you have a fast disk subsystem or a battery backed caching controller, file-based persistence can be quite a bit faster than JDBC.
The following table shows parameters of key resources used by your Oracle WebLogic Integration application that you should monitor in the Oracle WebLogic Server Administration Console, and actions you should take if a problem condition arises.
For more information, see “How JDBC Connection Pools Enhance Performance” in
Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.
|
|||
For more information, see Tuning Oracle WebLogic Integration Applications.
|
|||
Create a thread execute queue named
wli.internal. , and increase the number of threads in that pool.
For more information, see
Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.
|
|||
Create a thread execute queue named
wli.internal. , and increase the number of threads in that pool.
For more information, see
Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.
|
If you have deployed your application as an exploded EAR, you can increase the amount of time that elapses before a transaction times out by increasing the value of trans-timeout-seconds
in the Oracle WebLogic Server Administration Console. You should also change this value in the source for your Oracle WebLogic Integration application so that the value of trans-timeout-seconds
is not reset to its default value when you redeploy the application.
If you have not deployed your application as an exploded EAR, trans-timeout-seconds
is not accessible through the Oracle WebLogic Server Administration Console. You must increase the value of trans-timeout-seconds
in your application, and then redeploy the application with the increased timeout value.
For information on how to change the value of trans-timeout-seconds
, see “Edit Deployment Descriptors” in
Implementing Enterprise Java Beans in Programming Oracle WebLogic Enterprise JavaBeans.
The top causes of memory leaks are:
For more information, see Using Flags to Start Oracle WebLogic Server and Maximize Performance.
To reduce JMS timer messages, see Increasing the Transaction Timeout Period.
The following section provides answers to questions about configuring Oracle WebLogic Integration applications for recovery. It contains the following topics:
You should check to make sure your Oracle WebLogic Integration application is configured in the following manner:
cgPool
.Best Practices for Oracle WebLogic Integration Application Life CycleNote: | If you need to change the targeting of one or more JMS servers in an active cluster, you must restart the cluster after you make changes to the targeting configuration. |
WLI Admin
component of WLI System EJBs
is targeted to the cluster. You can verify the targeting of WLI Admin
by inspecting its configuration in the config.xml
file for the WLI System EJBs
application.Note: | WLI Admin can be targeted to the cluster only when JMS servers are targeted to migratable targets. |
If you need to tune your retries and retry intervals, you have the following choices:
retry-count
and retry-interval
in your JPDs.retry-count
and retry-interval
of the async and error queues for each JPD project (WebApp). Note: | This will break explicit retry settings on the JPD, but it is the easiest and recommended approach. |
For more details, see JMSQueue in the Oracle WebLogic Server Configuration Reference.
JTA
attribute TimeoutSeconds
in the config.xml
file is set to a value less than the value of the JDBCConnectionPool.XA
TransactionTimeout
attribute for XA connection pools.
For more information about TimeoutSeconds
, see
JTA in the Oracle WebLogic Server Configuration Reference.
JTA
attribute MaxTransactions
in the config.xml
file is set to a value large enough to accommodate the number of simultaneous transactions that could occur on a server during recovery. For transaction intensive applications, you should increase the value of this attribute from the default setting.
For more information about MaxTransactions
, see
Domain-->Configuration-->JTA in the Oracle WebLogic Server Administration Console Online Help.
JDBCConnectionPool
attribute MaxCapacity
in the config.xml
file is set to a value greater than the value of the execute queue ThreadCount
attribute.
For more information about MaxCapacity
, see
JDBCConnectionPool in the Oracle WebLogic Server Configuration Reference.
For information about Server
ThreadCount
, see “Tuning the Default Execute Queue Threads” in
Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.
dba_2pc_pending
, dba_2pc_neighbors
, and dba_pending_transactions
must have the right permissions for recovery to be called. If they do not, you will get a database error and recovery will fail. It can take several minutes for in-doubt transactions to show up in Oracle. There may be a race if recovery has started prior to Oracle detecting the loss of the TM. Wait several minutes before starting recovery—either by restarting the server or by doing a JTA migration.
The Recovery process will fail if after initiating recovery, you check the Oracle dba_2pc_pending
table and see a record associated with the failed server that has a timestamp prior to initiating recovery. Restart the server.