Hot memory buffer has two major functions. First, it caches incoming (new) documents. Second it caches documents swapped in from disk as a result of a disk hit. It is not obvious what documents should be cached in memory if any. To further understand how Squid memory buffer works, we track down the memory hits that correspond to documents that were never swapped in:

When a document is retrieved from its source, it is placed into memory buffer. Later, a document is swapped out to free space for incoming requests. However, before the document content is freed from memory buffer, it may be requested by other clients. Such requests result in no swap-in memory hits that we are interested in. These hits are interesting because they show how effective memory buffer is in caching new (previously uncached) documents.

There are hits and hits. We consider four hit categories or classes:

• Disk hits: Hits that were resolved by reading content from disk. Only 200 replies are considered.
• Memory hits: Hits that were resolved by sending content from memory. The requested document was in the hot memory buffer and, thus, no disk activity was necessary. Only 200 replies are considered.
• IMS hits: The client sent an If-Modified-Since request. The object was in the cache and still fresh. This corresponds to the TCP_IMS_HIT action in Squid. Note: The cache may have more recent data than the client, so Squid may send the full body with the new content. It is still a hit from Squid point of view.
• 304 hits: IMS hits (see above) with 304 reply code. Note that the 304 code guarantees that the object was not read from disk and its content was not sent to a client.
• Negative hits: Hits with reply code other than 200 or 304.

To illustrate relative importance of each class, we plot the percentage of all hits a class represents.