WebLogic Integration Solutions Best Practices FAQ

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Performance Tips

The following sections provide answers to questions about designing and tuning high-performance WebLogic Integration applications. It contains the following topics:

 


Design-Time Performance Issues

This section answers the following questions:

Which types of processes are faster—stateful or stateless?

Stateless processes are significantly faster than stateful processes.

Which controls are faster—process or service?

Process controls are faster than service controls.

Which callback methods are faster—process control callbacks or message broker subscriptions?

You get approximately the same performance when starting a process using the process control or message broker, but it is significantly faster to receive a process control callback than a message broker subscription. The message broker subscription filter mechanism uses a database to map the filter values to process instances. Process control callbacks are routed directly to the process instances.

How can I get better performance from parallel nodes in my business processes?

By default, the branches of a parallel node are transactionally isolated. You can override this behavior by setting the continueTransaction property in the source for each parallel element as follows:

<parallel continueTransaction="true">

Why do my JMS queues show so many pending messages?

Timer messages (messages set with a delivery time in the future) show up as "pending messages" in the WebLogic Server console.

How can I get rid of pending JMS timer messages?

For stateful processes, turn off maximum conversation lifetime if you are not using it:

weblogic.jws.Conversational

For more information on the conversation lifetime feature, see "@jws:conversation-lifetime Annotation" in Java Web Service Annotations in the "WebLogic Workshop Reference" in WebLogic Workshop Help.

How can I increase the transaction timeout period?

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:

Note: The wlw-config.xml file is same for both the 8.1 and 9.2 releases.

For recovery considerations regarding transaction timeout periods, see What should I check to make sure my WebLogic Integration application is configured properly for recovery?

 


Run-Time Tuning Issues

This section answers the following questions:

What flags should I use when I start WebLogic Server to maximize performance?

For optimum performance, use the following flags when starting 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.

How do I tune WebLogic Integration Applications?

WebLogic Integration projects map onto J2EE resources. The primary EJB pools you can tune within a 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 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:

For background information on tuning in general, see WebLogic Server Performance and Tuning at the following location:

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/index.html

Can I configure the value of max-beans-in-free-pool for the JMS event generator?

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 WebLogic Server EJBs in WebLogic Server Performance and Tuning.

When should I version a stateful business process?

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 WebLogic Integration Solutions.

Which process tracking levels should I use to optimize performance?

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 WebLogic Integration Solutions.

Do I need to run the Archiver if the process tracking levels are set to none?

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 WebLogic Integration Solutions.

How do I turn off informational Web services messages?

Edit <domain-home>/apacheLog4jCfg.xml and change all occurrences of info to warn.

When should my WebLogic Integration application use the document store?

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 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.

Which is the best persistence model for JMS—file-based persistence or JDBC?

If you have a fast disk subsystem or a battery backed caching controller, file-based persistence can be quite a bit faster than JDBC.

What should I watch for when monitoring a WebLogic Integration application running under load?

The following table shows parameters of key resources used by your WebLogic Integration application that you should monitor in the WebLogic Server Administration Console, and actions you should take if a problem condition arises.

Table 1-1 Parameters to Monitor in WebLogic Integration Applications
Parameter
Where to Monitor
Problem Condition
Actions Required
JDBC connection pool usage
ServicesArrow symbolJDBC Data SourcesArrow symboleach data-sourceArrow symbolMonitoring.
Connections in use approaching maximum available.
Increase the MaxCapacity attribute of JDBCConnectionPool.
For more information, see "How JDBC Connection Pools Enhance Performance" in Tuning WebLogic Server in WebLogic Server Performance and Tuning.
JMS async queues for project beans
ServicesArrow symbolMessagingArrow symbolJMS ModulesArrow symbolconversational-jms.
Many messages in the queue.
Increase the pool size for the AsyncDispatcher.
wli.internal.tracking.buffer
ServicesArrow symbolMessagingArrow symbolJMS ModulesArrow symbolconversational-jms.
Many messages in the queue
Create a thread execute queue named wli.internal.
ProcessTracking
, and increase the number of threads in that pool.
For more information, see Tuning WebLogic Server in WebLogic Server Performance and Tuning.
wli.internal.instance.info.buffer
ServicesArrow symbolMessagingArrow symbolJMS ModulesArrow symbolconversational-jms.
Many messages in the queue
Create a thread execute queue named wli.internal.
ProcessTracking
, and increase the number of threads in that pool.
For more information, see Tuning WebLogic Server in WebLogic Server Performance and Tuning.

How can I reduce the number of transactions timing out?

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 WebLogic Server Administration Console. You should also change this value in the source for your 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 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 WebLogic Enterprise JavaBeans.

Why does my application seem to leak memory?

The top causes of memory leaks are:


  Back to Top       Previous  Next