Skip to main content

WebLogic Performance Tuning – Thread Management

The deployed application on Web Logic Server requires the availability of resources to execute the received service request and provide the corresponding response back to the application users.

All services are executed through Threads in the Web Logic Server. Each request serviced by the available thread from the Thread Pool. Thus, it is important to ensure that the available threads are not consumed completely and resulting into the Thread Deadlock and impacting the Web Logic Server performance.

Management of Threads in Previous Release before Web Logic 9.0
Till the previous Web Logic 9.0 Release, separate execute queues were maintained for different type of work (service request) executed by the Web Logic Server and users were provided with the creation of user defined thread pool. Thus, Web Logic admin had to manage multiple execute queues and multiple thread pools and required more time for diagnosing the exact reason for the consumption of stuck threads.
Management of Threads through Single Thread Pool
Web Logic Server provides Single Thread Pool and Single Execute Queue from Release 9.0 onwards.
How it works then with Single Thread Pool and overcome performance issue? Web Logic Server executes the received request based on priority. All type of work (service request) executed through Single Thread Pool and automatically maintains the Thread Count (increase / decrease of threads) and thus self –tuned itself.

Web Logic Server introduced Work Manager, which acts as the mechanism to prioritize the work and allocate the threads from the Thread Pool based on the rules defined for execution. The Web Logic Admin can use the pre-defined rules provided by the server or can setup the rules considering the run time performance, throughput and monitoring activities.

Below given are the pre-defined Rules /Constraints provided by Web Logic Server:

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 Manager Types:
The Work Managers are classified into below given 3 types
1. Default Work Manager: If the application does not specify the Work Manager, then Web Logic Server Default Work Manager will be used to handle the thread management and request processing. It also manages self-tuning to avoid performance issues.
2. Global Work Managers: The global work manager will be available to all the deployed applications in the Web Logic Server. The application uses the work manager as a template. Each application will get its own instance at run time and thus Work Manager can execute respective application requests separately based on application instance.
3. Application Scoped Work Managers: Work Manager can be created in such a way that they perform requests for a specific application or module deployed in the Web Logic Server.

The application scope work managers can be defined in the Web Logic Admin console or can be added through the below given description files in the application
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
What is the ideal situation to use Work Managers?
The Work Manager can be used when the below reasons are valid for the deployed application(s)
1. The default fair share (50) is not sufficient. This happens when multiple applications are deployed and one of the application request have more priority.
2. When it is required to set the response time goal.
3. When minimum thread constraint value need to be provided to avoid server deadlock

Copy Protected by Chetan's WP-Copyprotect.