|
|
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.
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.
By default, 16 threads are allocated to AsyncDispatcher because of WLS self-tuning. 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.
WLI has the following EJBs for each project:
You can tune the pool size of these EJBs to handle high load. Note that two or more JPDs in the same project share the same EJB. In the following scenarios, consider splitting the project into smaller projects:
For information on how to tune EJB pool for these EJBs, see Tuning EJB Pools in Tuning WebLogic Server EJBs.
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 max-beans-in-free-pool set to 5.
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.
|