1.2.4 WebSphere Funnel model
.
Figure 1-4 Queue tuning points in a J2EE Web site: the Funnel model
In Figure | -4 decreasing values are assigned to the tuning parameters for each of the displayed Web site components. This deliberate reduction in the maximum number of available resources assigned to each successive layer is called the Funnel model methodology. The benefit of the funnel tuning model is that we want as many clients to connect to our system as possible, but without overwhelming the resources in each of the layers downstream (for example, database connections). The funnel helps us place these requests into various queues at each layer, where they will wait until the next layer has the capacity to process them. In summary, the funnel model helps us handle bursts of client requests without inundating the back-end application or database servers. Figure | -5 provides an example of some queue tuning parameters.
| Note: When configuring WebSphere Commerce we recommend that the Datasource connection pool is equal to the servlet thread pool plus the number of scheduler threads plus one. Every incoming request to a Commerce system requires a connection to the database, even if caching is being used, to avoid deadlock. |
Figure 1-5 IBM HTTP Web server request handling, queue settings, and architecture
As shown in figure Figure | -5, Web requests arriving at the Web server plugin are initially stored in a Listen queue, with a maximum depth set to MaxConnectBacklog. The MaxConnectBacklog value is a custom property configured in the application server. The Web server will hold up to MaxConnectBacklog pending connection requests for the application server, and then will reject any further requests until the application server has processed some of the outstanding connection requests.
In the application server an Accepting thread pulls one request at a time from the Listen queue, and stores it in the Accepted Connection Queue. The request waits in the Accepted Connection Queue until it is processed by the Selector thread.
In WebSphere Application Server v6 the selector threads unblock the Web container threads from the connection threads.
Why so many queues?
Queues handle overflow requests. Their primary functions are to:
| Allow the HTTP requestor to make a connection |
|
| Enable the request to wait in the queue to receive service without being lost |
Queuing is especially useful for handling sudden, major increases in traffic conditions, such as when a larger than normal number of clients hit the Web site simultaneously. The downside of queuing is that it may impact your failover/outage detection capabilities. Failover detection is usually triggered by a failure to connect, and large queues can mask outage situations; hence delay the failover. The WebSphere Application Server infocenter describes in great detail the various queues and other parameter settings that you may need to tune. You can access this information at:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm. websphere.nd.doc/info/ae/ae/tprf_tuneprf.html