INTERPRETATION OF THE RESULTS
What is a web server?
The web server is a program running on a networked machine, waiting for connections from the outside world to serve certain documents on behalf of a request by a browser. To communicate, the server and the browser use an asynchronuous communication method called the HTTP (hypertext transaction) protocol. It works as follows:
The document delivered as an answer to this request may contain inline objects. Inline objects are simply URLs pointing to another resource, either a document, an image, an applet, a video/audio stream, or any other addressable HTML object.
The browser then requests all inline objects of the current page from the server using the steps 2 and 3 above, before it can display the content of that page.
GET /img/raglogo.png HTTP/1.1 GET /img/bt_ha.png HTTP/1.1 GET /img/bt_td.png HTTP/1.1 GET /img/bt_inet.png HTTP/1.1
This communication method is called asynchronuous, because the browser sends out many requests for inline documents at once (without waiting for a response from the server before sending the next request) using different communication channels:
Since the browser's requests are often
handled by different server processes or different threads of a server process,
there is absolutely no relationship between the logfile entries caused by the
responses from the server due to a request of a document and it's inline
What kind of information is logged by the web server?
Each and every response from the server - whether it indicates success, an error, or even a timeout (i.e. no response) - gets logged in the server's logfile. Since the server was hit by a request, such a reponse is called a Hit. In other words, the total number of hits must equal the total number of lines in the logfile minus the number of corrupt and empty lines. A typical logfile entry in the Common Logfile Format looks like:
hostname - - [01/Feb/1998:10:10:00 +0100] "GET /index.html HTTP/1.1" 200 2750
The hostname field contains the full qualified domain name (FQDN) of the site accessing your server (see »Special Cases« below). The next two fields usually contain a minus (`-') to indicate that those fields are empty. The date is surrounded by square brackets ('[' and ']'). The next field contains the request. It contains the request method (GET for example), the name of the requestet document (URI), and the protocol specification (HTTP/1.1). The following field contains the servers's response code (200 stands for an »OK«, while 404 would mean »Document not found«, for example). The last field contains the size of the document (some servers log the number of bytes transferred actually, while other servers log the size of the document, which makes a difference if the user interrupts the transfer before the document could be transmitted completely.
There are two other logfile formats, the Combined or Extended Logfile Format. Those formats add the user-agent (browser type) and the referrer URL (the page, which contains a link to the requested document if this request for such document has been generated by following a link) to the logfile entry. Those Combined or Extended Logfile Format append following two fields to the Common Logfile Format (CLF) in one of two usual ways:
Mozilla/2.0 (X11; IRIX 6.3; IP22) http://foo/bar.html "http://foo/bar.html" "Mozilla/2.0 (X11; IRIX 6.3; IP22)"
Note that in the second form, the user-agent and the referrer URL are surrounded by double quotes, which makes them ambiguous in certain cases such as errorneous referrer URLs, which contain double quotes. Therefore, the first form should be preferred if possible.
The entries shown above are the only information the server records in the logfile. There might be much more information being transferred from the browser to the server, but although this additional information is available through CGI-scripts running on your server, it gets not logged in the logfile. Therefore, http-analyze can only show you a summary of the information in the logfile - nothing more, nothing less.
In the example outlined above entries like the following would get logged by the web server:
isp.com - - [05/Feb/2004:10:10:00 +0100] "GET /index.html HTTP/1.1" 200 2750 isp.com - - [05/Feb/2004:10:10:00 +0100] "GET /img/raglogo.png HTTP/1.1" 200 3407 isp.com - - [05/Feb/2004:10:10:00 +0100] "GET /img/bt_inet.png HTTP/1.1" 200 294 isp.com - - [05/Feb/2004:10:10:00 +0100] "GET /img/bt_ha.png HTTP/1.1" 200 314 isp.com - - [05/Feb/2004:10:10:01 +0100] "GET /img/bt_td.png HTTP/1.1" 200 302
The order in which responses are logged is not necessarily the same as the order in which the requests have been received by the server. From this information you can get the sitename isp.com, the date, the request type GET, the URI (for example, /index.html, the protocol method HTTP/1.1, the response code Code 200 (OK) and the size of the document or image sent back to the browser. The number of hits would be five, but actually there was only one page requested. Therefore only the index.html is counted as a PageView, so the numbers of PageViews gives an idea how much documents have been requested. Still, this is not the number of visitors!
If you would have logged the referrer URL for those requests, it could either have been empty for the first file index.html (if the URL was typed in manually) or contains the location of a link which was followed to reach this URL on your site. In case of the four images the referrer URL would be your site (a so-called self-referring URL). Note that a browser can send any string as the referrer and some actually do so just for fun.
Caching in browsers
As soon as a page has been saved in a browser's disk cache, the browser might send out conditional requests for documents or inline objects. This conditional request ask the web server to only send a document/object if it has been modified since the last time the page has been requested (if the page is still in the browser's cache). This way, network traffic is reduced somewhat, since documents must be transferred only if they have changed recently. If such a conditional request arrives, the server will respond with a Code 304 (Not Modified) status to indicate that the document hasn't changed or with a Code 200 (OK) status if it has changed in the meantime. Since the browser may be configured (and usually is so by default) to only send out such conditional requests once per session and otherwise unconditionally use the copy from the cache, you may not even see a Code 304 response if this users visits your site again in the same session. Conditional requests are then sent out only if the user terminates the browser session and later restarts the browser.
Caching in proxy servers
Organizations with a large number of users - such as companies, universities, or online providers - often use a so-called proxy server for mainly two reasons:
Both forms of caching make it technically impossible to count visitors or to track their way through your web site. All you see in the logfile of your server is only a few initial hits from the proxy or browser and probably some Code 304 responses resulting from conditional requests sent out by the proxy or browser, depending on the preferences settings of the proxy or browser.
Definition of terms
The statistics report contains among others the following information:
The following table summarizes the meaning of all terms in the statistics report which are not self-explaining:
[ Homepage |
Product Description |
Licensing & Pricing |
Download Area |
Sample Report |
Customer Support ]
Impressum · Copyright © by RENT-A-GURU®