Maximum Performance with WebSphere Application Server V5.1 on iSeries

Chapter 6. Tuning the IBM HTTP Server (powered by Apache) 207

Figure 6-3 Setting the number of threads for a specific server

6.5.2 Triggered Cache Manager

Each time the client requests a page, the HTTP request must go through this process:

1. It goes through the network and passes each communication component such as firewall,

routers, proxies, and so on.

2. It goes through the HTTP Server (powered by Apache) to identify that the request must be

redirected to an application server.

3. The application server must in turn call the application.

4. The application processing the request may have to rely on many large object (LOB)

database queries (or any other required tasks) to generate the dynamic content of the

HTML page.

5. Even after the HTML is generated, this response must flow all the way back down the line.

If a different client or even the same client requests the information again, the whole process

must be repeated. Even if the application has an application cache that can reduce the

number of queries into the LOB database, the amount of processing required to place to the

object stored in the application cache can be extremely large.

If you extend this environment to one with hundreds or even thousands of clients, CPU cycles

(alone) required to process the requests increase considerably. At this point, it may be better

if the implementation included a mechanism to serve client requests without going through

the whole process every time.

In this implementation, you create the dynamic content in a proactive fashion and copy it to

the iSeries IFS or perhaps a router with a cache mechanism. Either way, now when the client

sends the request, dynamic content is already cached in the iSeries IFS or router. In this way,

the request can be processed with less demand on server resources and the response time

for the client improved.