Performance Tuning Part - 3 : Work Managers

1]. WebLogic Server allows you to configure how your application prioitizes the   

     execution of its work. 

2]. Based on rules you define and by monitoring actual runtime performance, WebLogic   

     Server can optimize the performance of your application and maintain service level  

     agreements. 

3].  You define the rules and constraints for your application by defining a Work Manger  

      and applying it either globally to WebLogic Server domain or to a specifi  

      application component.

4]. In WebLogic Server 9.0 there is 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.

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

6]. Administrators can configure a set of scheduling guidelines and associate

     them with one or more applications, or with particular application components.

For example,

  

you  can associate one set of scheduling guidelines for one application, and another  

  set of guidelines for other application. At run-time, WebLogic Server uses these

  guidelines to assign  pending work and enqueued requests to execution threads.

7] .

Work Managers can be configured at the domain level, application level, and module level in one of the following configuration files:

• config.xml—Work Managers specified in config.xml can be assigned to any application, or application component, in the domain. You can use the Administration Console to define a Work Manager.
• weblogic-application.xml—Work Managers specified at the application level in can be assigned to that application, or any component of that application.
• weblogic-ejb-jar.xml or weblogic.xml—Work Managers specified at the component-level can be assigned to that component.
• weblogic.xml—Work Managers specified for a Web Application.

Work Manager Stanza

<work-manager>

<name>highpriority_workmanager</name>

   <fair-share-request-class>

      <name>high_priority</name>

      <fair-share>100</fair-share>

   </fair-share-request-class>

   <min-threads-constraint>

      <name>MinThreadsCountFive</name>

      <count>5</count>

</work-manager>

To reference the Work Manager listed above in the dispatch policy of a Web Application, add the below code into the Web Application's web.xml file:

Referencing the Work Manager in a Web Application

<init-param>

   <param-name>dispatch-policy</param-name>

   <param-value>highpriority_workmanager</param-value>

</init-param>

8]  To manage work in your applications, you define one or more of the following Work Manager 

     components:

• Fair Share Request Class:
• Response Time Request Class:
• Min Threads Constraint:
• Max Threads Constraint:
• Capacity Constraint
• Context Request Class:

• fair-share-request-class—Specifies the average percentage of thread-use time required to process requests.

For example, assume that WebLogic Server is running two modules. The Work Manager for ModuleA specifies a fair-share-request-class of 80 and the Work Manager for ModuleB specifies afair-share-request-class of 20.

During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, WebLogic Server will allocate 80% and 20% of the thread-usage time to ModuleA and ModuleB, respectively.

• response-time-request-class—This type of request class specifies a response time goal in milliseconds. Response time goals are not applied to individual requests. Instaead, WebLogic Server computes a tolerable waiting time for requests with that class by subtracting the observed average thread use time from the response time goal, and schedules schedule requests so that the average wait for requests with the class is proportional to its tolerable waiting time.

For example, given that ModuleA and ModuleB in the previous example, have response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, and no "think time" delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms., the average response time for ModuleB requests is 2,500 ms.

• context-request-class—This type of request class assigns request classes to requests based on context information, such as the current user or the current user's group.

• max-threads-constraint—This constraint limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.

A max-threads-constraint can be defined in terms of a the availability of resource that requests depend upon, such as a connection pool.

A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair share of threads or meeting its response time goal. Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.

• min-threads-constraint—This constraint guarantees a number of threads the server will allocate to affected requests to avoid deadlocks. The default is zero. A min-threads-constraint value of one is useful, for example, for a replication update request, which is called synchronously from a peer.

A min-threads-constraint might not necessarily increase a fair share. This type of constraint has an effect primarily when the server instance is close to a deadlock condition. In that case Then, however, it the constraint will cause WebLogic Server to schedule a request from a even if requests in the service class have gotten more than its fair share recently.

• capacity—This constrain causes the server to reject requests only when it has reached its capacity. The default is zero. Note that the capacity includes all requests, queued or executing, from the constrained work set. Work is rejected either when an individual capacity threshold is exceeded or if the global capacity is exceeded. This constraint is independent of the global queue threshold.