About Web Cache
The Web Cache application provides HTTP content caching: as web traffic passes through the Untangle Server it will be transparently cached. This will both save bandwidth by serving repeat content from the local cache and improve user experience by loading cached sites faster.
Just like the Web Filter and other applications on Untangle, Web Cache works transparently on traffic passing through the Untangle Server. There is no need to change any of the settings on any of the PCs behind Untangle to gain the benefits of web caching.
As content is downloaded from the web it is stored in a local cache on the disk. Upon later requests of the same web document the content is served directly from the local cache. The same document does not get downloaded multiple times, and the client gets a better user experience because they don't have to wait on subsequent downloads of the same document.
This section reviews the different settings and configuration options available for Web Cache.
The Status tab displays statistics from Web Cache - there are no settings to configure.
- Statistics: The following information will help you understand the statistics Web Cache provides:
- Cache Hit Count displays the total number of HTTP requests that have been served from cache.
- Cache Miss Count displays the total number of HTTP requests that were not found in cache and thus were served using content retrieved from the external server where the content resides.
- Cache Hit Bytes displays the size, in bytes, of all HTTP requests that have been served from cache.
- Cache Miss Bytes displays the size, in bytes, of all HTTP requests that were not found in cache.
- User Bypass Count displays the number of HTTP sessions that bypassed the cache because the server hosting the content was listed in the user managed cache bypass list.
- System Bypass Count displays the number of HTTP sessions that bypassed the cache because the system determined they were not compatible with our caching model. Web Cache can generally handle all GET and HEAD requests, and we also allow smaller POST requests to transit through the cache logic. Everything else (ie: Large POST requests, non HTTP traffic, etc.) will be allowed to bypass the cache entirely.
- Clear Cache: If content stored in the cache somehow becomes stale or corrupt, the cache can be cleared with the Clear Cache button. As noted in the GUI, clearing the cache requires restarting the caching engine, which will cause active web sessions to be dropped and may disrupt web traffic for several seconds.
The Cache Bypass tab allows you to enter sites you do not want cached. Some sites to not operate properly with Web Cache working (such as Google Maps, which is bypassed by default) so you may need to add some sites to this list. Just hit Add, fill in the domain name, and save.
The Reports tab provides a view of all reports and events for all traffic handled by Web Cache.
This applications reports can be accessed via the Reports tab at the top or the Reports tab within the settings. All pre-defined reports will be listed along with any custom reports that have been created.
Reports can be searched and further defined using the time selectors and the Conditions window at the bottom of the page. The data used in the report can be obtained on the Current Data window on the right.
Pre-defined report queries:
|Web Cache Summary||A summary of Web Cache actions.|
|Cache Hit-Miss Statistics||The number of cache hits, misses, and sessions bypassed over time.|
|Cache Size Statistics||The amount of cached and uncached web data over time.|
|Web Cache Events||All HTTP events processed by Web Cache.|
The tables queried to render these reports:
Web Cache FAQs
Is Web Cache based on an open source project?
Yes, Web Cache is based on Squid.
How does Web Cache work?
The WebCache rack node subscribes to all port 80 traffic. Each client request is forwarded to the squid cache running on the local appliance. If the cache has the content stored locally, we transmit the response directly to the client, allowing all the other nodes and services to act on the content as required, and life is grand. That's called a cache hit, and it's really pretty simple.
The real magic kicks in when handling a cache miss. In this case, we can't allow squid to go grab the content and hand it directly to the client like it normally would. We need the response to pass through all of the other apps and services. So we got a little creative with the Squid setup by configuring all external content to come from a peer cache. That peer cache is actually another thread within our WebCache node. When Squid connects back to us for a cache miss, we allow the original request to continue outbound as it normally would, and we intercept the response from the external server. This allows us to push a copy of the content into Squid while also returning it to the client at the same time.
Is Web Cache a "proxy?"
Web Cache is not a proxy, nor does it provide proxy functionality.