This order of magnitude performance improvement on hits suggests that the Harvest cache can serve as an httpd accelerator. In this configuration the cache pretends to be a site's primary httpd server (on port 80), forwarding references that miss to the site's real httpd (on port 81). Further, the Web administrator renames all non-cacheable URLs to the httpd's port (81). References to cacheable objects, such as HTML pages and GIFs are served by the Harvest cache and references to non-cacheable objects, such as queries and cgi-bin programs, are served by the true httpd on port 81. If a site's workload is biased towards cacheable objects, this configuration can dramatically reduce the site's Web workload.
This approach makes sense for several reasons. First, by running the httpd-accelerator in front of the httpd, once an object is in the accelerator's cache all future hits will go to that cache, and misses will go to the native httpd. Second, while the httpd servers process forms and queries, the accelerator makes the simpler, common case fast [14]. Finally, while it may not be practical or feasible to change the myriad httpd implementations to use the more efficient techniques advocated in this paper, sites can easily deploy the accelerator along with their existing httpd.
While the benefit of running an httpd-accelerator depends on a site's specific workload of cacheable and non-cacheable objects, note that the httpd-accelerator cannot degrade a site's performance. Further note that objects that don't appear cacheable at first glance, can be cached at some slight loss of transparency. For example, given a demanding workload, accellerating access to ``non-cacheable'' objects like sport scores and stock quotes is possible if users can tolerate a short refresh delay, such as thirty seconds.