Understanding How WebLogic Server Uses Thread Pools

2 Using Work Managers to Optimize Scheduled Work 2-1 2 Using Work Managers to Optimize Scheduled Work WebLogic Server lets you configure how your application prioritizes the execution of its work. Based on rules you define and by monitoring actual run-time performance, WebLogic Server can optimize the performance of your application and maintain service-level agreements. You define the rules and constraints for your application by defining a Work Manger and applying it either globally to a WebLogic Server domain or to a specific application component. ■ Section 2.1, Understanding How WebLogic Server Uses Thread Pools ■ Section 2.2, Understanding Work Managers ■ Section 2.3, Work Manager Scope ■ Section 2.4, Using Work Managers, Request Classes, and Constraints ■ Section 2.5, Deployment Descriptor Examples ■ Section 2.6, Work Managers and Execute Queues ■ Section 2.7, Accessing Work Managers Using MBeans ■ Section 2.8, Using CommonJ With WebLogic Server

2.1 Understanding How WebLogic Server Uses Thread Pools

In previous versions of WebLogic Server, processing was performed in multiple execute queues. Different classes of work were executed in different queues, based on priority and ordering requirements, and to avoid deadlocks. In addition to the default execute queue, weblogic.kernel.default, there were pre-configured queues dedicated to internal administrative traffic, such as weblogic.admin.HTTP and weblogic.admin.RMI. You could control thread usage by altering the number of threads in the default queue, or configure custom execute queues to ensure that particular applications had access to a fixed number of execute threads, regardless of overall system load. Now WebLogic Server uses a single thread pool, in which all types of work are executed. WebLogic Server prioritizes work based on rules you define, and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool. The common thread pool changes its size automatically to maximize throughput. The queue monitors throughput over time and based on history, determines whether to adjust the thread count. For example, if historical throughput statistics indicate that a higher thread count increased throughput, WebLogic increases the thread count. 2-2 Configuring Server Environments for Oracle WebLogic Server Similarly, if statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the thread count. This new strategy makes it easier for administrators to allocate processing resources and manage performance, avoiding the effort and complexity involved in configuring, monitoring, and tuning custom executes queues.

2.2 Understanding Work Managers