Welcome!

Websphere Authors: Yeshim Deniz, Liz McMillan, Roger Strukhoff, Rajiv V. Joshi, Bruce W. McGaughy

Related Topics: Websphere

Websphere: Article

How to Optimize WebSphere Application Server Performance

Best Practices for Harnessing Thread Pools

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.

Figure 1 displays an application request flow that requires back-end processing and illustrates the relationship among the thread pools as the user request is processed.

HTTP Listener
The HTTP Listener is responsible for thread creation at the HTTP server level. Most of the processing that occurs here is static page serving, or HTTP post/GET pass commands to the back end. This is the first level of thread configuration that must be considered.

Web Container
The Web container is responsible for thread pool creation at the application server level. Most of the processing at this level includes servlet, JSP, EJB, dynamic page creation, and back-end pass-through processing. The Web container is the second level of thread pool configuration that must be configured.

ORB Container The ORB container is responsible for thread pool creation at the object level. Most of the processing that occurs here includes the processing of non-Web?based clients. The ORB container is the third level of the thread pool configuration that must be configured.

Data Source
The data source level is responsible for creating the connection threads that are accessed from the database or "legacy" systems. These threads are the fourth level of configuration that must be addressed.

Thread Pool Funnel
When considering requests that are processed by the application, developers should consider Web architecture design and associated business processes. In many instances, more processing is required at the site's front-end systems than at the site's back-end systems. Because the number of requests requiring threads is greater at the front end of a Web site, the higher number of threads is required at layer one and is then reduced for each subsequent layer. This configuration produces a funnel effect in which thread requirements are reduced as the administrator configures each of the four layers. If the thread pool amounts were equal, the system could overload at each pool location, thereby saturating the entire WAS environment.

Therefore, when setting thread pool minimum and maximum parameters for specific thread pools, developers are often able to create a thread pool funnel that will produce the best results for a site. The thread pool funnel is displayed in Figure 2.

Some of the requests to a Web site only require static page returns. These requests are merely services at the HTTP listener layer, and do not require Web container, ORB container, or data source threads. These requests simply make it to the HTTP listener layer (see layer one in Figure 2), and then provide the user with the static response.

In another scenario, the application may only have to process at the Web container layer, perhaps hitting a JSP and getting returned dynamic page content. When this type of processing occurs, the user request requires threads for processing at the HTTP Listener and Web container layers. However, neither the ORB container nor data source processing is required.

The third scenario based on yet another type of inquiry, such as a non-Web Java application that would require processing. To service this request, a thread is acquired at the HTTP listener, Web container, and ORB container layers. In this case, processing at the data source layer was not required.

The final example, one which demands thread acquirement at all levels, includes a service rendered from the data source. A CICS transaction, for example, must be executed for the users' requests to be serviced via an EJB. In this final scenario, the users' requests required threads to be acquired at the HTTP Listener, Web container, ORB container, and data source layers.

It is important to note that when a flood of requests occurs in a thread pool funnel, each request will wait its turn at the appropriate queue rather than overloading all queues. The thread pool funnel provides a mechanism to minimize the potential for requests to overload the application server, significantly slowing performance or even crashing the system.

Conclusion
The thread pool funnel concept was first introduced in the Performances Analysis for Java report last year by Joines, Willenborg, and Hygh. Although the thread pool funnel is not pertinent in all J2EE application architectures, it is an effective design pattern that can increase application performance significantly. I have seen many customers who have implemented this concept reduce the end user's wait time, decrease the potential for application server saturation, and increase business productivity.

References

  • Gunther, N. (2004). How to Get Unbelievable Load Test Results. Retrieved November 10, 2003, from Performance Dynamics Company Web site: www.teamquest.com/resources/gunther/load-test.shtml
  • Joines, S., Willenborg, R., & Hygh, K. (Eds.). (2003). Performance Analysis for Java. Persons Education, Inc.
  • Willenborg, R. (2002). Monitoring Performance with WebSphere. Retrieved October 11, 2003, from the e-Pro Magazine Web site: www.e-promag.com/eparchive/ index.cfm?fuseaction=viewarticle&ContentID=1492&websiteid=
  • Zhang, Y., Liu, A., & Qu, W. (2003). Software Architecture Design of an Autonomic System. Retrieved November 10, 2003, from the University of Sydney Web Site: http://mercury.it.swin.edu.au/ctg/AWSA04/Papers/zhang.pdf
  • More Stories By Michael S. Pallos

    Michael S. Pallos, MBA, is a Senior Solution Architect for Candle Corp. and has 18 years of experience in the IT industry. Mr. Pallos is consultant to some of Candle's largest corporate customers, a featured speaker at industry conferences, and a doctorial student at Walden University, earning his Ph.D. in Applied Management and Decision Sciences - Information Systems Management. Candle, based in El Segundo, Calif., provides solutions to manage and optimize business-critical infrastructures, systems, service levels and other information technology assets. More than 3,000 of the world's largest companies use Candle products and consulting services, including 73 percent of the Global 100. Mr. Pallos can be reached at Michael_Pallos@candle.com

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.