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
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.