Reference : Weblogic Enterprise Architecture
In Today's Blog I have summarized the WorkManagers Internals for newbie's
After Reading the below you will have complete understanding of Internal Mechanism of the WM's
which will be very useful in Performance tuning the weblogic servers.
In Today's Blog I have summarized the WorkManagers Internals for newbie's
After Reading the below you will have complete understanding of Internal Mechanism of the WM's
which will be very useful in Performance tuning the weblogic servers.
Execute
Threads and WorkManagers
Prior to WebLogic Server 9.0, we use to configure execute queues
with a fixed thread count and a pending work queue length. However, dealing
directly with low-level kernel attributes such as the number of threads has
problems
With WebLogic Server 9.0 administrators can move away from
configuring dedicated execute queues and start describing application
requirements in a language they understand
Weblogic 8.1 and Below -->
Execute Queues
Weblogic 9.0 and Above -->WorkManagers
New
Thread Pool Implementation WebLogic Server 9.0 and Above
From WebLogic Server 9.0 and above has a single thread pool for
requests from all applications. Similarly, all pending work is enqueued in a
common priority-based queue. The thread count is automatically tuned to achieve
maximum overall throughput. Priority of the requests is dynamic and computed
internally to meet the stated goals. Administrators state goals simply, using
application-level parameters like fair-share, response time goals.
In earlier releases, each servlet or RMI request was associated
with a dispatch policy that mapped to an execute queue. Requests without an
explicit dispatch policy use the server-wide default execute queue. In WebLogic
Server 9.0, requests are still associated with a dispatch policy but are mapped
to a WorkManager instead of to an execute queue.
Requests without an explicit dispatch policy use the default WorkManager of the application.
This means that each application has its own default WorkManager that is not
shared with other applications. This distinction is important to note. Execute
queues are always global whereas WorkManagers are always application scoped.
Even WorkManagers defined globally in the console are application scoped during
runtime. This means that each application gets into own runtime instance that
is distinct from others, but all of them share the same characteristics like
fair-share goals. This is done to track work at the application layer and to
provide capabilities like graceful suspension of individual applications.
As mentioned earlier, each servlet or RMI request is associated
with a WorkManager. By default, all requests are associated with the
application default WorkManager. The dispatch-policy element can be used to
associate a request with a specific WorkManager either defined within an
application scope or globally at the server level. I will provide examples on
how to use the dispatch policy in a later section.
Thread
Count Self-tuning
One of the major differences between execute queues and the new
thread scheduling model is that the thread count does not need to be set. In
earlier releases, we defined new thread pools and configured their size to
avoid deadlocks and provide differentiated service. It is quite difficult to
determine the exact number of threads needed in production to achieve optimal
throughput and avoid deadlocks. WebLogic Server 9.0 and Above is self-tuned,
dynamically adjusting the number of threads to avoid deadlocks and achieve
optimal throughput subject to concurrency constraints. It also meets objectives
for differentiated service. These objectives are stated as fair shares and
response-time goals as explained in the next section.
The self-tuning thread pool monitors the overall throughput
every two seconds and uses the collected data to determine if thread count
needs to change. Present thread count, the measured throughput, and the past history
is taken into account by the algorithm to determine if the thread count needs
to increase or decrease, and new threads are automatically added to the pool or
removed, as needed.
What
Is a WebLogic WorkManager?
As mentioned above, WebLogic Server 9.0 and above maps incoming
requests to a WorkManager instead of executing queues. Let's now look at what a
WorkManager is and does. A WebLogic WorkManager is the runtime abstraction into
which requests are submitted by WebLogic Server containers for asynchronous execution.
Multiple WorkManagers can be present, and the choice of which WorkManager to
use is determined during deployment. Administrators can change the WorkManager
for any servlet or EJB dispatch by using deployment descriptors. Each
WorkManager can contain four types of components:
1.
Request class (fair-share, response-time goal, context based)
2.
Minimum threads constraint
3.
Maximum threads constraint
4.
Capacity
It is important to note a couple of things before we proceed.
These four components are optional. In addition, the components can be shared
between WorkManagers. For example, two or more WorkManagers can share the same
request class, which means that they get the same internal priority. Another
simple example could be when WorkManagers share the same capacity. This means
that the sum total of requests from all WorkManagers that share the capacity
will not exceed the specified limit.
How
Are WorkManagers Resolved During Runtime Execution?
As mentioned in the previous section, applications set a
dispatch policy to associate request entry points with named WebLogic
WorkManagers. During deployment, each module looks at the configured dispatch
policy and maps the servlet or EJB method call to a particular WorkManager
instance. It is possible to map multiple method calls to a single WorkManager
instance. All user requests made to that particular method call or servlet
invocation will be automatically dispatched to the associated WorkManager and
therefore get its properties. Applications can be redeployed with a new
dispatch policy.
Thread
Dump Changes
In WebLogic Server 8.1 and earlier releases, threads belonging
to execute queues could be identified in the thread dump using the name of the
execute queue. That has changed in WebLogic Server 9.0 and Above. Since all
WorkManagers use the common thread pool, thread dumps will not be able to
identify which threads belong to which WorkManagers. This is because threads
are shared by all WorkManagers. All execute threads have the term
"self-tuning" in their names to indicate that they belong to the
common self-tuning pool. The thread names are prepended with their states. The
three states that appear in the thread names are:
1.
ACTIVE: The
thread is active and is executing work or is ready to pick up work when it
arrives.
2.
STANDBY: The
thread is removed from the active thread pool and is not picking up work. It
can still execute work from the minimum threads constraint work set if the
constraint is not met. The self-tuning implementation has removed this thread
from the active pool since it is not improving throughput. It can be moved back
into the active thread pool if needed later.
3.
STUCK: A
thread is stuck executing work for more than the configured stuck thread
interval. The thread could be stuck due to a deadlock or a slow responding back
end connection.
To
Summarize:
Did you know that that you can generate dollars by locking special pages of your blog / website?
ReplyDeleteTo begin you need to join AdscendMedia and use their Content Locking tool.