| only for RuBoard - do not distribute or recompile | |
A.7 Cachability
Table A-10 shows the cachability percentages for different classes of responses. This data comes from an analysis of Squid's store.log files. Squid writes an entry in this file for every object saved to disk and every object that is released from the cache. Objects are released either because they are uncachable or to free up space for new objects. For each URL, I count the number of times it is successfully written to disk and the number of times it is not cached. Releases made by the cache replacement algorithm are ignored. If it is cached more times than not, the object is cachable . If it is not cached more times, it is uncachable. If the counters are equal, then the object's cachability is unknown.
Table A-10. Response Cachability (IRCache Data)
| Type | % Cachable | % Uncachable | % Unknown |
| All | 75.9 | 23.9 | 0.2 |
| text/html | 36.7 | 63.1 | 0.2 |
| image/* | 90.9 | 8.9 | 0.2 |
This analysis represents the cachability of an object rather than a response. It does not include popularity effects. The IRCache data does not lend itself to a response-based analysis of cachability because the IRCache proxies receive a higher-than-normal percentage of requests for uncachable objects. The child caches filter out most of the cache hits but not the cache misses; the misses find their way to the top of the hierarchy. I compensate for this by looking at unique URLs rather than each request.
| only for RuBoard - do not distribute or recompile | |
