Maximum Performance with WebSphere Application Server V5.1 on iSeries

208 Maximum Performance with WebSphere Application Server V5.1 on iSeries

Triggered Cache Manager (TCM) is a component in the iSeries server that was created

exactly for this purpose. This component is packaged in the IBM HTTP Server for iSeries,

5722-DG1 Option 1. TCM is a Transmission Control Protocol (TCP) server. This server may

be used in conjunction with Web servers and Web document caching agents to keep Web

sites running at peak performance.

TCM is:

 A cache manager, not a cache or cache server

 Based on trigger messages

This means that you must set up application triggers for the server to work. These

messages are sent to the TCM via the HTTP protocol.

 A stand-alone server that can work with multiple types of caching mechanisms, for

example caching routers, proxy caches, and so on

It is useful in the environment that we describe here for the HTTP Server (powered by

Apache), but it can be used for the HTTP Server (original), Lotus® Domino®, or

WebSphere Application Server environments as well.

TCM is proactive (based upon updates to an LOB database) in the update of Web content.

TCM causes the Web content to be dynamically regenerated and then placed in a location

(usually the iSeries IFS) that was configured to be served as static content by your Web

server. The TCM is most effective for a Web site that has a large number of requests for

content that is somewhat constant, but changes frequently.

One of IBM’s first uses of the TCM concept was to drive the 1996 Summer Olympic Games

Web site. For example, a downhill skiing results page (mostly HTML) was composed of

hundreds of dynamic items including names, times, scores, and so on for a particular event.

For every request of that page, consider if the application server had to re-run all the

database queries to dynamically calculate the content. That level of activity could have

weighed heavily on the server with many repetitive actions. Only when the application LOB

data was updated with new results, then the application server was used to update a standard

results page to be served from a “static” portion of your Web site. This tremendously reduced

the burden on the application server.

For more information, read HTTP Server (powered by Apache): An Integrated Solution for

IBM Eserver iSeries Servers, SG24-6716.

6.5.3 mod_deflate

mod_deflate is a tool used to compress files server from the HTTP Server. This is done

through the configuration files and is the equivalent of Apache’s mod_gzip. When Web

content or files are compressed, it reduces the amount of bandwidth required to send the

information. The data is eventually decompressed on the client side in the Web browser. Keep

in mind that additional resources are consumed to compress and decompress the content.

Unless you expect or suspect bandwidth issues, mod_deflate is not necessary.

6.5.4 Logging

There are several different areas of logging to consider for the HTTP Server. And depending

on your needs or performance problem, you may or may not want them collecting detailed

information. Remember, the more you collect, the more resources are used to write to disk.

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

Access logs

One of the most important tuning options when it comes to logging has to do with the Access

Log. By default, this log is turned on, and all HTTP requests are captured.

To turn off the HTTP server Access Log, follow these steps:

1. Access your HTTP server configuration page in IBM Web Administration for iSeries.

2. Under Tools, click Edit Configuration File.

3. Search for a line with the text CustomLog (see Figure 6-4). Comment out this line by placing

the pound symbol (#) in front of the line.

Figure 6-4 Disabling the access log

4. Save and close the configuration file.

5. Restart the IBM HTTP Server.

The default value for the access logs is

enabled for an incoming HTTP request. The

recommended value for performance reasons is to disable the access logs.

Error logs

The error log for the HTTP Server can be setup at several different levels. Depending on that

level, your performance can degrade. The bottom line is that the more you log, the more

resources are consumed and the performance of your application decreases. Different levels

of logging are:

 Emergency

 Alert

 Critical

 Error

 Warning

 Notice

 Informational

 Debug