A cache hierarchy is just what you might expect—an arrangement of caches that cooperate with each other. In a cache hierarchy, the lower layers forward cache misses up to the higher layers until a cache hit is found or the request is sent to the origin server. Cache hierarchies are attractive because they can offer performance improvements. Some of the requests that are misses in your cache will be hits in your neighbor’s caches. This further reduces wide-area network bandwidth and improves download speeds.
However, you must carefully consider a number of important issues surrounding hierarchies, such as trust, freshness, scalability, and effects on routing. These are particularly important when the members of the hierarchy are controlled by different organizations. It’s often awkward and difficult to participate in a hierarchy in the absence of an existing business relationship. Large organizations, especially, are more comfortable being self-sufficient rather than relying on others.
In this chapter, we’ll talk about hierarchies in general, focusing on definitions and issues. In Chapter 8, we’ll learn about the protocols that make meshes and hierarchies possible. Caching proxies use these protocols to decide which neighbor, if any, should be the next hop for a particular request.
Web cache hierarchies can be complicated and amorphous. We use the terms parent, child, and sibling to describe the relationship between any two caches. Sometimes neighbor or peer are used to refer to either a parent or a sibling relationship, just to confuse you.
A child cache forwards its cache misses to a parent. The parent cache then provides the child with a response from its own cache, the origin server, or another cache. A parent cache may use bandwidth to origin servers to satisfy a child cache’s request.
Sibling relationships, on the other hand, are designed to prevent one cache from incurring costs on behalf of another. All requests sent to a sibling should result in cache hits. The sibling should never have to fetch an object requested by its peer. If the sibling doesn’t have the object cached, it returns a message that indicates its unwillingness to forward the request. A cache communicates with its siblings using one of the intercache protocols described in the next chapter. These protocols allow a cache to find out whether the neighbors have a particular object in their caches. A request should only be sent to a sibling if the intercache protocol predicts it will be a cache hit. As we’ll see later, hit predictions are not always accurate, so we need a way to deal with false predictions.
These relationships (parent-child, sibling-sibling) are not fixed. One cache might be a parent to some caches and a sibling to others. This type of configuration is sometimes used by large ISPs, which act as a parent for requests to their customer’s origin servers and as a sibling for all other requests.
The terms parent and sibling map well into a hierarchical topology, as shown in Figure 7-1. Parents are considered to be one level up from their child caches. Sibling caches are on the same level with each other. The only way to go up the hierarchy is through a parent cache. Other topologies, such as the one in Figure 7-2, are not really hierarchical. For these, the term mesh may be used instead.
The relationship between two caches is not necessarily symmetric. In other words, just because cache A sends requests to cache B, it does not mean that B can also send requests to A. If requests are to flow both ways, there should be a relationship defined for each direction. In practice, siblings usually have symmetric, bidirectional relationships. Parents and children, on the other hand, usually do not. Since there are no strict rules, it is possible to create some rather strange and complicated topologies. Two caches may have a sibling relationship in one direction but a parent relationship in the other. Of course, a child cache may have any number of parents.