The cache keeps all meta-data for cached objects (URL, TTL, reference counts,
disk file reference, and various flags) in virtual memory. This consumes
48 bytes + strlen(URL) per object on machines with 32-bit words 
. The cache will also
keep exceptionally hot objects loaded in virtual memory, if this option is enabled.
However, when the quantity of VM dedicated to hot object storage exceeds a parameterized
high water mark, the cache discards hot objects by LRU until VM usage hits
the low water mark. Note that these objects still reside on disk;
just their VM image is reclaimed.
The hot-object VM cache is particularly useful when the cache is deployed as an
httpd-accelerator (discussed in Section 3.1).
The cache is write-through rather than write-back. Even objects in the hot-object VM cache appear on disk. We considered memory-mapping the files that represent objects, but could not apply this technique because it would lead to page-faults. Instead, objects are brought into cache via non-blocking I/O, despite the extra copies.
Objects in the cache are referenced via a hash table keyed by URL. Cacheable objects remain cached until their cache-assigned TTL expires and they are evicted by the cache replacement policy, or the user manually evicts them by clicking the browser's ``reload'' button (the mechanism for which is discussed in Section 5.1). If a reference touches an expired Web object, the cache refreshes the object's TTL with an HTTP ``get-if-modified''.
The cache keeps the URL and per-object data structures in virtual memory but stores the object itself on disk. We made this decision on the grounds that memory should buy performance in a server-bottlenecked system: the meta-data for 1,000,000 objects will consume 60-80MB of real memory. If a site cannot afford the memory, then it should use a cache optimized for memory space rather than performance.