Tuning the default WorkManager on WebLogic Server

Hi Everyone,

Best Wishes...@@@ Hope you all are doing well ..... @@@

Today one of my friend came across scenario where he needs to tune weblogic default work manager. so today i am sharing few steps for tuning default work managers.

In my last post we have got brief idea of Work managers, now in this post we will talk about tuning of default work managers.

In WLS 8, we had the concept of Execute Queues, replaced by work-managers, starting with WLS 9. Well, it's got self-tuning, allows a large number of SLA combinations.

So lets Play with the default work-manager :)

The default work-manager, as its name tells, is the work-manager defined by default.Thus, all applications deployed on WLS will use it.

But sometimes, when your application is already in production, it's obvious you can't take your EAR / WAR, update the deployment descriptor(s) and redeploy it.

The default work-manager belongs to a thread-pool, as initial thread-pool comes with only five threads, that's not much.

If your application has to face a large number of hits, you may want to start with more than that.Well, that's quite easy. You've got two ways to do so.

Option 1) Modifying the config.xml

Just add the following line(s) in your server definition :

    <server>

    <name>AdminServer</name>

    <self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min>

    <self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max>

    [...]

    </server>

Option 2) Adding some JVM parameters

Personally, that's my favorite option since I don't like when people go in a generated config file

and mess up with tags. If you're sure of what you're doing, that's ok, but it's safer the following way :

add the following option in your command line : -Dweblogic.threadpool.MinPoolSize=100

Personally, I decided to apply the change by adding the JVM parameter.

To do so, I just updated the startWeblogic (in Domain_home) script with the USER_MEM_ARGS line.

@REM WARNING: This file is created by the Configuration Wizard.
@REM Any changes to this script may be lost when adding extensions to this configuration.

SETLOCAL

set DOMAIN_HOME=F:\Oracle\Middleware\user_projects\domains\base_domain
set USER_MEM_ARGS=-Dweblogic.threadpool.MinPoolSize=100
call "%DOMAIN_HOME%\bin\startWebLogic.cmd" %*

ENDLOCAL

(Note : I'll recommend use Option 2 )


Reboot WLS and see the option has been taken into account  :) 

Wasn't so hard, was it ? :) 

feel free to write me on middlewaresolution1@gmail.com.

Enjoy Working with Middleware technologies.

Regards,

Ajinkya Vichare

ajinkya-vichare.blogspot.com

Introduction to Work Managers

Hi Everyone,

Best Wishes..  Hope all are doing well..!!

Today lets talk about work managers in oracle Weblogic server.

In earlier version there is concept called execute threads, BEA and IBM has come up with concept called work managers, we will check both concept one by one.

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.

With introduction of Work Managers, weblogic server helps to prioritize work and allocate the threads based on an execution model. The is taken care by the administrator-defined parameters after observing the actual run-time performance, throughput, monitoring, etc. Defining of this behaviour or rules is done at the different levels differently for differently for different applications, group of applications, etc as per the requirement. We can define one or more of the following Work Manager components in our deployment descriptor or config files:

1) Fair Share Request Class:

2) Response Time Request Class:

3) Min Threads Constraint:

4) Max Threads Constraint:

5) Capacity Constraint

6) Context Request Class

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

a) 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.

b) weblogic-application.xml — Work Managers specified at the application level can be assigned to that application, or any component of that application.

c) weblogic-ejb-jar.xml or weblogic.xml — Work Managers specified at the component-level can be assigned to that component.

d) weblogic.xml — Work Managers specified for a Web Application

The scope of the work managers could be any of the following three:

1) The default Work Manager

2) Global Work Managers

3) Application-scoped Work Managers

Default Work Manager:

These are used to handle thread management and perform self-tuning.This Work Manager is used by an application when no other Work Managers are specified in the application’s deployment descriptors.

In many situations, the default Work Manager may be sufficient for most application requirements. WebLogic Server’s thread-handling algorithms assign each application its own fair share by default. Applications are given equal priority for threads and are prevented from monopolizing them.

Global Work Managers:

These have the scope of the domain. Global Work Managers are created in the WebLogic Administration Console using the following steps:

Step a) Login to WebLogic Admin Console and click on the left Panel “Work Manager”.

Step b) Then click on “Lock and Edit” button and click on “New” button from right panel

Step c) Select “Work Manager” radio button from Select Work Manager Definition type then click on Next.

Step d) Give the work Manager Name and click Next.

Step e) Now Target it to any Server or Cluster.

Step f) Now click on “Finish” and then “Activate Changes”

These are then defined in config.xml.

An application uses a globally defined Work Manager as a template. Each application creates its own instance which handles the work associated with that application and separates that work from other applications. This separation is used to handle traffic directed to two applications which are using the same dispatch policy. Handling each application’s work separately, allows an application to be shut down without affecting the thread management of another application. Although each application implments its own Work Manager instance, the underlying components are shared.

Application-scoped Work Managers:

 In addition to globally-scoped Work Managers, you can also create Work Managers that are available only to a specific application or module. Work Managers can be specified in the following descriptors:

a) weblogic-application.xml

b) weblogic-ejb-jar.xml

c) weblogic.xml

If you do not explicitly assign a Work Manager to an application, it uses the default Work Manager.

you can also check following URL for more details

http://docs.oracle.com/cd/E11035_01/wls100/config_wls/self_tuned.html

Feel free to write me on middlewaresolution1@gmail.com.

Enjoy working with Middleware technologies..

Regards,

Ajinkya Vichare 

ajinkya-vichare.blogspot.com