A Work Manager defines a set of request classes and thread constraints that manage work performed by WebLogic Servers. This page displays the global Work Managers, request classes and thread constraints defined for this domain.
Global Work Managers are defined at the domain level. You can also define
application-level and module-level Work Managers
- Response Time Request Class
- Fair Share Request Class
- Context Request Class
- Maximum Threads Constraint
- Minimum Threads Constraint
- Capacity Constraint
Request
Classes
A
request class expresses a scheduling guideline that WebLogic Server uses to
allocate threads to requests. Request classes help ensure that high priority
work is scheduled before less important work, even if the high priority work is
submitted after the lower priority work. WebLogic Server takes into account how
long it takes for requests to each module to complete
There
are multiple types of request class, each of which expresses a scheduling
guideline in different terms. A Work Manager may specify only one request
class.
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 a fair-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.
|
The value of a fair share request class is specified as a
relative value, not a percentage. Therefore, in the above example, if the
request classes were defined as 400 and 100, they would still have the same
relative values. |
- 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. Instead, 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 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.
For example, the context-request-class
in Context Request Class assigns a request class to requests based on the value of the
request’s subject and role properties.
A
context request class allows you to define request classes in an application’s
deployment descriptor based on a user’s context. For example:
Listing 2-3 Context Request
Class
<work-manager>
<name>responsetime_workmanager</name>
<response-time-request-class>
<name>my_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
</work-manager>
<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
Above,
we explained the request classes based on fair share and response time by
relating the scheduling to other work using the same request class. A mix of
fair share and response time request classes is scheduled with a marked bias in
favor of response time scheduling.
A
constraint defines minimum and maximum numbers of threads allocated to execute
requests and the total number of requests that can be queued or executing
before WebLogic Server begins rejecting requests.
You
can define the following types of constraints:
- 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, the constraint will cause WebLogic Server to
schedule a request even if requests in the service class have more requests
than its fair share recently.
- capacity—This constraint causes the server to reject requests
only when it has reached its capacity. The default is -1. 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.
·
Understanding Execute Queues and Work
Managers
·
Execute Queues: The main purpose
of having the Execute Queues is to handle the request internal and
external related to weblogic server. Here, external requests could be the
requests related to:-
·
1) applications
deployed inside the weblogic server
·
2) redirection
requests from weblogic server to the database, etc
·
Internal requests could be either the
communication between the managed servers or between the managed server and
admin server, etc.
·
These requests are mainly handled using the
threads. Hence, we can conclude that the Execute Queues are mainly used for
thread management. This management is achieved by using the using the different
queues like weblogic.kernel.default, weblogic.admin. HTTP, weblogic.admin.RMI,
etc.
·
Work Managers: With the
release of the new versions of weblogic server and new advancement the execute
queues or the thread management in weblogic server also had the enhancements.
From Weblogic Server 9x we had a replacement done to Execute Queues with the
introduction of Work Managers.
Work Managers:
WebLogic Server is self-tuning in
nature by default, that is, it adjusts the thread size as needed.
WebLogic Server uses a single thread
pool whose size changes automatically to maximize throughput. This process is
called server self-tuning. The queue monitors throughput over time and based on
history and determines whether to adjust the thread count. The server increases
or decreases pool size if a higher or lower thread count increases performance.
All the work is executed within this pool.
WebLogic Server prioritizes work
based on rules defined by an administrator 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. 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.
Default Work Manager:
• All applications are given
equal priority.
• A default fair share of threads
is given to each application.
• If no Work Manager is
explicitly assigned to an application, it uses the default Work Manager.
• The default Work Manager can
be overridden by creating and configuring a global Work Manager called default.
Work Manager Scheduling Guidelines:
• Use when the default fair
share is insufficient.
• Use to schedule work based
on application priority.
• Use when applications
require different response times.
• Use to avoid server
deadlocks.
Components of Work Manager:
– Request Classes.
– Constraints.
Request Classes:
Request classes help schedule work
based on priority.
Three types of request classes:
• fair-share-request-class
• response-time-request-class
• context-request-class
Fair Share Request Class:
The fair share request class
specifies the average percentage of thread-use time required to process
requests.
• Configuration options: Name
and Fair share value
• Default value: 50
• Minimum value: 1
• Maximum value: 1000
Fair Share Request Class
The fair share request class
specifies the average percentage of thread-use time required to process
requests.
Snippet: high priority fair share request class
<fair-share-request-class>
<name>high_priority</name>
<fair-share>90</fair-share>
</fair-share-request-class>
Snippet: low priority fair share request class
<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>
Response Time Request Class:
The response time request class
specifies a response time goal in milliseconds.
• Configuration options: Name
and Goal (milliseconds)
• Default value: 0
Snippet: fast response request class
<ModuleA>
<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>1000</goal-ms>
</response-time-request-class>
Snippet: slow response request class <ModuleB>
<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>8000</goal-ms>
</response-time-request-class>
Context Request Class:
The context request class assigns
request classes to requests based on context information, such as the current
user or the current user’s group.
•Configuration options: Name and
context case
Snippet: context request class
<context-request-class>
<name>simple_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
Constraints:
• A constraint defines:
– The minimum and maximum
numbers of threads allocated to execute requests
– The total number of requests
that can be queued or executing before WebLogic Server begins rejecting
requests
• Types of constraints:
– max-threads-constraint
– min-threads-constraint
– capacity.
Maximum Threads Constraints:
The maximum threads constraint
limits the number of concurrent (simultaneous) threads that can execute
requests sharing this constraint.
Configuration options:
– Name: The user-specified
name
– Count: Thread count (Default
value: -1)
– Data Source: The name of the
connection pool whose size is taken as the maximum constraint
Snippet: maximum threads constraint
<max-threads-constraint>
<name>max_threads</name>
<count>10</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>
Minimum Threads Constraints:
The minimum threads constraint
guarantees a minimum number of concurrent threads that the server allocates to
requests sharing this constraint.
Configuration options:
– Name: The user-specified
name.
– Count: Thread count (Default
value: -1)
Snippet: minimum threads constraint
<min-threads-constraint>
<name>min_threads</name>
<count>1</count>
</min-threads-constraint>
Capacity Constraints:
The capacity constraint causes the
server to reject requests only when it has reached its capacity to avoid server
deadlocks.
Configuration options:
– Name: The user-specified
name
– Count: Thread count (Default
value: -1)
Snippet: capacity constraint
<capacity-constraint>
<name>my_capacity</name>
<count>50</count>
</capacity-constraint>
Referencing Classes or Constraints:
A Work Manager is defined by
encapsulating one request class and/or one constraint to schedule requests.
Configuration options:
– Name and request
class/constraint
Snippet: Work Manager
<work-manager>
<name>priority_work_manager</name>
<fair-share-request-class>
<name>very_high_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>min_five_Threads</name>
<count>5</count>
<min-threads-constraint>
</work-manag
No comments:
Post a Comment