(Dist) Queuing network

WebSphere Application Server contains interrelated components that must be harmoniously tuned to support the custom needs of our end-to-end e-business application. These adjustments help the system achieve maximum throughput while maintaining the overall stability of the system.

This group of interconnected components is known as a queuing network. These queues or components include the network, web server, web container, EJB container, data source, and possibly a connection manager to a custom back-end system. Each of these resources represents a queue of requests waiting to use that resource.

Various queue settings include the following. Consult the associated topics in the information center.

• IBM HTTP Server: MaxClients for operating systems such as AIX or Linux and ThreadsPerChild for Windows NT systems. Read about web server plug-in tuning tips to learn more about these settings.
• Web container: Maximum size described in "Thread pool settings", MaxKeepAliveConnections and MaxKeepAliveRequests described in "HTTP transport custom properties".
• Tune Object Request Brokers explained in "Tuning application servers".
• Data source connection pooling is discussed in "Connection pooling" and statement cache size is explained in "Data source settings".

Most of the queues that make up the queuing network are closed queues. A closed queue places a limit on the maximum number of requests present in the queue, while an open queue has no limit. A closed queue supports tight management of system resources. For example, the web container thread pool setting controls the size of the web container queue. If the average servlet running in a web container creates 10 MB of objects during each request, a value of 100 for thread pools limits the memory consumed by the web container to 1 GB.

In a closed queue, requests can be active or waiting. An active request is doing work or waiting for a response from a downstream queue. For example, an active request in the web server is doing work, such as retrieving static HTML, or waiting for a request to complete in the web container. A waiting request is waiting to become active. The request remains in the waiting state until one of the active requests leaves the queue.

All web servers supported by WAS are closed queues, as are WAS data sources. We can configure web containers as open or closed queues. In general, it is best to make them closed queues. EJB containers can be open or closed queues. If there are no threads available in the pool, a new one is created for the duration of the request.

If enterprise beans are called by servlets, the web container limits the number of total concurrent requests into an EJB container, because the web container also has a limit. The web container limits the number of total concurrent requests only if enterprise beans are called from the servlet thread of execution. Nothing prevents you from creating threads and bombarding the EJB container with requests. Therefore, servlets should not create their own work threads.

Subtopics

• Queuing and clustering considerations
  Cloning application servers to create a cluster can be a valuable asset in configuring highly scalable production environments, especially when the application is experiencing bottlenecks that are preventing full CPU utilization of symmetric multiprocessing (SMP) servers.
• Queue configuration best practices
  A methodology exists for configuring the WAS queues. Moving the database server onto another machine or providing more powerful resources, for example a faster set of CPUs with more memory, can dramatically change the dynamics of our system.