Databases Reference
In-Depth Information
In this recipe, the default work manager was created to override the default configuration,
limiting the concurrency of all applications deployed. The default work manager handles the
application requests when no other work manager is defined. The work manager constraints
are valid per WebLogic Server, so this configuration limits the PROD_Server01, PROD_
Server02, PROD_Server03, and PROD_Server04 to execute a maximum of 50 concurrent and
simultaneous threads in each; or 200 concurrent threads, if counting the whole PROD_Cluster
(50 threads * 4 instances).
At peak time, when the default work manager already has 50 threads executing on a
Managed Server, the next request will be queued in the priority queue and wait until a thread
is free. This configuration avoids the Self-tuning Thread Pool increasing the number of threads
to a point that the WebLogic cannot handle the concurrency. On the other side, it also adds
the possibility of queuing some of the requests, with a possible impact in the response time.
The following graph illustrates the protected WebLogic. Even though it's receiving more than 50
incoming requests, the Managed Server processes only 50 simultaneously, maintaining the SLA.
There's more...
The default work manager can be created through WLST.
Creating the default work manager by using WLST
Carry out the following steps:
1. Log in as wls user to shell and start WLST:
[wls@prod01]$ $WL_HOME/common/bin/wlst.sh
2. Connect to the Administration Server using wlsadmin as the user, <pwd> as the
password and t3://adminhost.domain.local:7001 as the server URL:
wls:/offline> connect("wlsadmin","<pwd>","t3://adminhost.domain.
local:7001")
 
Search WWH ::




Custom Search