Maximum Performance with WebSphere Application Server V5.1 on iSeries

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

4.6.1 Server logging

Server logs are most useful for monitoring server activity and keeping track of user access as

well as being a valid aid in debugging performance issues. By carefully examining these logs,

you can discover the root cause when you experience an HTTP-related problem.

Figure 4-138 shows the options that you can set for HTTP logging.

Figure 4-138 HTTP performance: Server logging configuration

Error logs

HTTP servers created using browser-based wizard on the HTTP Administration page always

produce an error log by default. Look for error log files in the /logs subdirectory of your server

root. Basic error logs are most useful for debugging configuration problems, such as when a

document is not accessible or the Uniform Resource Identifier (URI) (the path you add after

the server address) you’re pointing to is not working as expected.

Error logs also keep track of configuration changes and server end and restart. Plus they

record some system errors. Be aware that any problem detected after server initialization is

most likely not recorded in the server’s QTMHHTTP job logs (unless a critical condition

occurs), but in the error log.

Figure 4-139 shows an example of what you may see in the error log of your HTTP server.

Figure 4-139 HTTP performance: Error logging

[Mon Jul 19 16:24:47 2004] [notice] Initializing the WebSphere Plugin

[Mon Jul 19 16:24:52 2004] [notice] Initializing the WebSphere Plugin

[Mon Jul 19 16:25:37 2004] [notice] Initializing the WebSphere Plugin

[Mon Jul 19 16:26:20 2004] [notice] ZSRV_MSG0385: Apache configured -- resuming normal

operations.

Chapter 4. Tools for determining performance problems 147

Access logs

If you choose to configure an access log for your HTTP server, information is recorded about

every access attempted. By default, the access log is stored in the /logs subdirectory of your

server root. Figure 4-140 shows an example of an entry from the access log.

Figure 4-140 HTTP performance: Access logging

Let’s dissect the access log entry in Figure 4-140. In Table 4-5, you can see that the first

column contains each of the elements that make up the access log entry in Figure 4-140. The

tokens in the second column are used to configure the logging format in the HTTP

configuration. The last column provides some detail about what each entry means.

Table 4-5 Understanding the HTTP access log

The error and access logs are but two of the available types of logging. You may also want to

track other activities, such as script interaction, to isolate and resolve performance concerns.

192.168.1.25 - - [19/Jul/2004:16:38:00 +0000] "GET /snoop HTTP/1.1" 200 15672 "-"

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"

Log entry Token Meaning

192.168.1.25 %h The remote host IP address.

- %l The user logged on to the remote system

In this case, the browser did not provide the

users name for security reasons.

- %u Name of the authenticated user

No user authentication is required yet.

19/Jul/2004:16:38:00 +0000 %t Date and time the request was served.

"GET /snoop HTTP/1.1" %r The request received

We can identify the method (GET), the URI and

the protocol used for this transaction (HTTP

version 1.1).

200 %>s The HTTP status code

200 means that this transaction was successful.

See Table 4-6 for more information about HTTP

status codes.

15672 %b The amount of data transmitted, in bytes

"-" %{Referer}

The page we came from

There is none in this case, since we manually

typed our address.

"Mozilla/4.0 (compatible; MSIE

6.0; Windows NT 5.1; .NET

CLR 1.1.4322)"

%{User-Agent} Information about the Web browser and

operating system in use by the client