This section describes the WLI parameters that you can tune in a production environment. This section discusses the following topics:
The ApacheLog4jCfg.xml
file located in the WLI domain directory specifies the WLI BPM logging configuration and the logging levels. You must set priority levels to ‘debug’ or ‘info’ only if such messages are required for debugging and testing purposes. In a production environment, you must set priority values to ‘warn’ or ‘error’ for all log appenders.
You must set the debug levels in the WebLogic Server console as the Worklist application creates a log on WebLogic Server as well as Log4j. See JMS Server: Logging for more information.
WLI uses the following JDBC data sources:
You must monitor these JDBC data sources and ensure that an adequate number of connections are available in the connection pool by modifying the values of Initial Capacity, Maximum Capacity, and Capacity Increment. It is recommended that InitialCapacity be set to MaxCapacity for your connection pool, so there is no time spent in growing or shrinking the pool.
If your application is heavily database driven, consider the following:
To minimize the time that an application takes to reserve a database connection from a data source and to eliminate contention between threads for a database connection, you can enable the Pinned-To-Thread
property for the data source. However, when this property is set, the connection remains with the execute thread and is not returned to the connection pool. If the pool does not contain any connection, more connections are created. These connections are more than what you specified in MaxCapacity. Therefore, use the PinnedToThread property only if it improves performance.
For more information, see Using Pinned-To-Thread Property to Increase Performance in WebLogic Server Performance and Tuning.
When you use a prepared statement or callable statement in an application or EJB, there is considerable processing overhead for the communication between the application server and the database server and on the database server itself. To minimize the processing costs, WLS can cache the prepared and callable statements used in your applications. It is recommended that you use Least Recently Used (LRU) algorithms and set cache size to the number of statements executed in your application. Determining the exact cache size is a trial-and-error process.
For more information, see Increasing Performance with the Statement Cache and Tuning Data Source Connection Pool Options in Configuring and Managing WebLogic JDBC.
The default WebLogic Server work manager configuration constrains the number of AsyncDispatcher requests being processed for a particular JPD project to a maximum of 16. Consequently, a maximum number of 16 threads can handle asynchronous requests for the project. Your system may not use this number of threads for CPU bound processing, as WebLogic Server tunes the number of threads dynamically to optimise throughput. However, for input/output bound processing, which is typical for WLI applications, you can remove the constraint by configuring a separate work manager for the project.
You can assign more threads by adding a separate workmanager to AsyncDispatcher, so more AsyncDispatcher MDB instances are created.
The same AsyncDispatcher MDB is used by all JPDs in a JPD project. In the following scenarios, consider splitting the project into smaller projects:
For more information, see Determining the Number of Concurrent MDBs in Tuning Message-Driven Beans.
The default HTTP-pooled connections per host is 2. To increase the pool size per host, you can use the following system property:
wli.httpcontrolmaxconnectionsperhost
The default HTTP-pooled connections for all hosts is 20. To increase the pool size for all hosts, you can use the following system property:
wli.httpcontrolmaxtotalconnections
WLI uses many internal queues in the conversational-jms module. By default, most of these queues use a persistent JDBC store.
If the queues do not require JDBC persistence, you can change it to 'Non-Persistent' or use the File Persistence parameter. The wli.internal.instance.info.buffer
queue used for process instance information can significantly improve the performance of WLI when the queue is changed to Non-Persistent.
Note: | Changing the persistence of a queue can cause data loss if the server or the machine crashes unexpectedly. |
For more information, see Tuning the WebLogic Persistent Store and Tuning WebLogic JMS in WebLogic Server Performance and Tuning.
By default, the JMS EG application created in the WLI domain directory has 16 MDB instances due to self-tuning.
You can try to increase the pool size to improve performance. If you want more than 16 MDB instances, you can assign a workmanager with a higher number of threads in the minimum and maximum thread constraints as the dispatch-policy of the EG.
For more information, see Determining the Number of Concurrent MDBs in Tuning Message-Driven Beans.
The weblogic.wli.DocumentMaxInlinSize
parameter in wli-config.properties
in the WLI domain directory specifies the maximum size of a document stored in the SQL Document Store. If a document (incoming message) is greater than the value specified in weblogic.wli.DocumentMaxInlinSize
, only document references are included in the message. Otherwise, the document is passed as a copy. If the message is large, the document store is contacted more frequently, thereby increasing database I/Os and decreasing memory usage. Therefore, the value of the threshold is important.
You can determine the size of your message, using Message Tracking. Tune the threshold value to improve performance. If a document is exchanged among many JPDs, you can use a document store to pass the relevant document reference on to the JPDs instead of passing the same data on to multiple JPDs.
Table B-1 lists the different levels of process tracking and the events generated. From performance perspective, the system performance degrades as we move from none to full level of process tracking.
If you change NONE to FULL, many more events are generated. These events lead to more database operations towards process instance information and process tracking data. You can partition the WLI_PROCESS_EVENT table, which is affected by higher levels of process tracking.
For more information about partitioning the WLI_PROCESS_EVENT table in Oracle9i Database Tuning Guide. For more information about process tracking, see Process Tracking Data in Using the WebLogic Integration Administration Console.
For trading partner integration, the following levels of message tracking are provided:
When you change the message tracking level from None to All, the database operations can have an impact on performance. For more information, see Configuring Trading Partner Management in Using the WebLogic Integration Administration Console.
In a scenario where database load is high, the worklist-reporting feature can have an impact on performance. This feature requires additional database operations for reporting. It is recommended that you move the reporting store to a different database machine by pointing a separate reporting datasource to a database machine other than p13ndatasource.
For more information about the default reporting store, see Default Reporting Store in Using Worklist.
Do not try to fetch all worklist task data at once. Your system slows down when the database contains a lot of tasks. You can use WorklistTaskQuery.getTaskDataCursor
to fetch a maximum of 1000 tasks from the database. WorklistTaskDataCursor
fetches tasks in batches, as specified in batchSize
.
If you are using WLI JMS control, you can set the send-with-xa
annotation of the WLI JMS control to true
for better performance with WLI.
The test console stores all logs in the JVM heap. You must clear the logs so that system performance is not affected.
By default, the test console (testConsoleFlag
in the setDomainEnv
file) is enabled for a development domain and disabled for a production domain. Do not enable the test console for production systems unless required for debugging purposes.
To control the behaviour of the JPD process meta-data cache you can do either of the following:
wlw.softDispReferences
system property to allow caching the meta-data using soft-references so that these references are relinquished when there is a memory crunch. The only drawback is that soft-references can significantly increase garbage collection times.com.bea.wli.dispatcher.cacheSize
property in the JAVA_PROPERTIES of setDomainEnv.cmd/sh
variable. This is a numeric value representing the boundary limits of the cache, which is interpreted as follows: