Organizations are increasingly using thread pools to enhance WebSphere Application Server performance by providing users with required information quickly without monopolizing resources required for other commands.
Regardless of the complexity of many J2EE applications, all that's important from the end user perspective, other than functionality, is processing time. The end user simply wants the requested HTML page to load quickly. Similarly, a business executive wants simple assurances that her organization is not losing customers due to slow Web site responses.
In the event that our response time is unacceptably slow, our competition is just a click away. As the old saying goes, "it is much easier to keep the customers you have than to get new ones." Successful Web site performance is key to a successful business and the Internet delivery channel.
The Pieces Of A Successful J2EE Application
There are many J2EE application transaction components, some of which afford us little or no control. Organizations, for example, have little control over the quality of customers' Internet connections to their Web sites or how the network path is routed in the Internet cloud. Fortunately, there are also many pieces of the Internet puzzle that organizations can manage and optimize, such as application servers, back end integration technologies, Java applications, and hardware. A successful IT "ecosystem" requires that each infrastructure component be tuned to optimize the entire IT system and support business performance. Organizations, for example, must ensure that Java application execution streams (threads) provide users with required information quickly and without monopolizing resources required for other commands.
This article will address best practices for harnessing thread pools in the application server environment, including the Hypertext Transfer Protocol (HTTP) listener, Web container (application container), the Object Request Broker (ORB) container (also referred to as the Enterprise JavaBean container), and the data source connection pool. This article will also explore the notion of a thread pool funnel.
Thread Pool Overview
As users request Web site information, threads are required to process these requests. When focusing on the WebSphere Application Server (WAS) environment, applications requesting a thread are acquired from either the HTTP Listener, Web container thread pool, ORB container thread pool, or the data source connection pool. The threads contained in these pools are the actual resources that service user requests. Therefore, tuning thread pools properly will enhance WAS performance and optimize the users' experiences.
The WAS administrative console is used to tune thread pools. Each thread pool is assigned a minimum and a maximum thread pool number. When WAS is launched, it will create the number of threads identified in the minimum thread pool number parameter. As application processing occurs, the system will generate additional threads as required, up to the maximum number of threads parameter. It is critical to set the maximum number of threads for any specific queue or command properly. If the system is constantly creating and destroying threads from the pool, system thrashing will occur, wasting valuable resources. When configuring a thread pool, it is important to remember that the "more is better" rule does not apply here. Threads require a memory commitment and system resources. If the thread pool is configured to produce more threads than the system requires, valuable system resources are being denied to other resources. This type of configuration will burden the system and slow the application. Therefore, configuring thread pools accurately and harmoniously with each other is critical to optimal WebSphere performance.
