Logging Page and Resource Hits
While our visitors may think that they are surfing from site to site across the Web in complete anonymity, we know that this isn’t actually true. OK, so we can't identify them absolutely unless we persuade them to log into our server with a password, for example, or by presenting a certificate. However, we can record and use some of the values that their browser automatically sends to our server with each request.
We've examined several of these values in earlier chapters of the book—back in Chapter 2 you saw the various headers that appear in the ASP ServerVariables collection, and we used the USER-AGENT header extensively in Chapter 4. Combining this information can provide us with useful statistics for judging the performance of our site.
Setting Up File Access Logging
Internet Information Server can log file accesses easily and automatically, to either a text file or an ODBC-enabled database. SQL Server using the latest ODBC driver seems to be an obvious choice. The connection pooling feature in ODBC will help to reduce the load on the server, because the connection should be in regular use and so will be available from the pool most of the time. However, if you wish to export the log files for analysis in other applications, you may prefer to store the information as a text file.
One regularly asked question is why we should use an enterprise-level system like SQL Server (usually running on a powerful and expensive machine) to do the logging, when we could use a much smaller fileserver and store the data in text files. Even if reporting is much easier (and faster) using SQL Server, you can always use a more powerful machine to analyze the data in the text files. This could be an attractive alternative for sites with very high traffic levels.
Specifying the Log File in IIS Manager
For both kinds of logging, setting up is via the Internet Information Service Manager. In IIS 4, this is a plug-in to the Microsoft Management Console (MMC). Simply right-click on the Default Web Site entry and select Properties, or use the drop-down Action menu. In the Web Site page of the Properties dialog, turn on Enable Logging and select the logging format you require:
.gif)
If you select ODBC Logging, the next step is to specify the connection information by clicking the Properties button in the same part of the dialog. You need to have a System DSN set up for use here (you can't use a connection string, as we've been doing so far with ADO), and specify the table name and the login details for the database:
.gif)
In IIS 3 or earlier, the process is very similar. Select the WWW service (rather than Default Web Site) in the Server Manager window and display the Properties dialog. The connection information you need to enter is the same.
If you are logging to a text file instead of an ODBC database, you get to specify details about how often a new log file is started by clicking the Properties button. And if you select W3C Extended Logging format in IIS 4, you can choose exactly which details to record. You then have many more items of information available than with the other two logging formats, such as the User Agent, Cookie and Referrer:
.gif)
Choosing Directories for Access Logging
One of the advantages Internet Information Server 4 has over earlier versions is that it allows us to specify the logging status of individual Web sites and directories. In IIS 3 and earlier, we could only specify that logging was on or off, and this state applied to the entire Web server. In IIS 4, in the Properties dialog for each site we host, we can set different logging options. Then, in the Properties dialog for each individual directory, we can specify whether logging will take place for that directory with the Log Access checkbox:
.gif)
There may be occasions where you don’t want to log all accesses. For example, if you have separate administration pages, you may wish to omit them from the list of logged directories in IIS 4 so that details of their path and the parameters you send to them are not recorded in the log file. This may help to prevent unauthorized local administrators or users discovering how to log on by examining the file.
Alternatively, particularly on an Intranet, you may want to log all accesses to administration pages or specific areas of the site, while omitting all other areas for space or performance reasons. This is particularly useful from a security-monitoring point of view. Bear in mind, however, that if you want to measure the total traffic volume over your network connection by using the log file, you'll need to enable logging on all directories and all sites.
Creating the ODBC Logs Table
If you decide to log to a database via ODBC, you must provide a table with the correct structure for IIS to write to. This structure is documented in the IIS Help files, and shown below:
.gif)
To make life easier, we've included a SQL script with the samples available for this book that you can use to create the table automatically on SQL Server, or any other database that can use SQL Server-syntax scripts for creating tables. Instructions on creating the table, and an appropriate database for it if required, are included with the sample files. You'll probably find that a similar file has already been installed by the IIS setup program in your Winnt\System32\inetsrv\ folder as Logtemp.sql:
.gif)
This table records all the information you might want about a particular file access, such as the user's IP address, the date and time, the number of bytes sent and received, and the parameters (the query string or other information) used to access the file. It also contains the name the Web server that received the request and sent the file out, and the IP address of the Web site that was accessed. This allows us to use a single log file for multiple servers (server farms) and multiple Web sites, making it easier to compile comparative data for different sites.
ODBC logging is particularly efficient if you have SQL Server running on a remote server, rather than on the same machine as the Web server. This allows IIS to fire off the INSERT statement that adds the entry to the log and get on with processing the request, without processor cycles being taken up by SQL Server. Multi-processor machines are obviously also a lot better able to handle ODBC logging than a single-processor machine.