Weblogic Threading

To improve WebLogic Server performance, use native I/O (performance pack) if available. To ensure that the performance pack is initialized correctly, check for errors at startup.

Execute queues can be set to automatically increase the threads during overflow condition. But avoid using the server's capability to increase the number of execute threads to manage normal application-load peaks. Rather, do careful capacity planning and server tuning; select an optimal number of execute threads.

Tips

1. Tune the execute thread count only if the CPU is not running at 100% utilization yet client requests are blocked and rejected too often.

2. When tuning the thread count, stop when throughput starts dropping or CPU utilization drops or stays constant.

3. Do not set the Stuck Thread Max Time and Stuck Thread Time Interval so low so that normal requests during peak processing time are mistaken for stuck threads.

4. To partition application components or to provide a dedicated amount of resources to one component, create user-defined execute queues. Using custom execute queues also avoids potential cross-server deadlock situations.

5. To provide a dedicated resource to message-driven beans, use a separate execute queue for each message-driven EJB that is deployed.

6. When troubleshooting deadlocks and long-running requests on WebLogic Server, use a series of properly spaced thread dumps to determine the possible causes.

7. Enabling T3 protocol access over HTTP by tunneling degrades performance by approximately 15%; avoid tunneling T3 over HTTP.

Testing Tips

1. During capacity planning and testing, plan for the peak load that an application might incur.

2. Optimize the application during testing; typically, on WebLogic Server, applications are the most-limiting factor in performance and capacity.

3. When you put a system under stress to test performance, use appropriate, realistic test cases.
4. The closer the test cases are to production situations, the more accurate the test results are.

5. When benchmarking applications, ignore the first few samples; run test samples to "warm up" the server VM.