7.2 Why Join a Hierarchy?

only for RuBoard - do not distribute or recompile

7.2 Why Join a Hierarchy?

As a cache administrator, you might wonder if you should participate in a cache hierarchy. The decision is not always an obvious one; there are many factors and issues for you to consider. People are usually motivated to peer with other caches either for improved performance or to force traffic along a non-default path .

7.2.1 Performance

Performance often motivates people to join a cache hierarchy. However, hierarchical caching is not a magic bullet; it is not guaranteed to improve your performance. If you seek better performance, you must first decide what is most important to you. Reduced bandwidth? Lower latency? In some situations, you may be required to trade one for the other. You should establish a system for measuring your cache's performance so you can quantitatively compare one configuration to another.

To realize improved performance with a cache hierarchy, the following points should all be true:

• Some of the objects not found in your cache will be found in your neighbor caches. In other words, you can get cache hits from your neighbors.

• Cache hits from neighbors are delivered more quickly than misses from origin servers.

• Cache misses from parent caches are not significantly slower than responses from origin servers.

If any of these are false, then your cache performance may actually suffer. Whether they are true or false depends on a number of factors. For example, if a parent cache is heavily loaded, then it may be slower than a direct connection to the origin server. Also, if your neighbor cache is far away, then cache hits may not be significantly faster. Furthermore, the behavior can change over time. One day your parent cache can be very fast but the next day very slow. Don't assume that conditions will always remain the same. Install some monitoring tools that can notify you if performance does not stay within certain thresholds.

7.2.2 Nondefault Routing

Parent caches are useful when you need to force web traffic along a specific route in your network. A common example of this is to get through a firewall. Many corporations and other organizations use firewalls to protect their internal network from the rest of the Internet. There are a number of different ways to deploy a firewall. Some do not allow internal users to communicate directly with external servers; they block outgoing connections for most ports, including port 80. In this case, the only way to reach the outside servers is through the firewall proxy, which is probably also a cache. If you have another caching proxy on the inside, then the firewall proxy is a parent for all of your requests to the outside.

It is increasingly common for corporations and other organizations to use interception proxying. Client HTTP connections are automatically diverted to a caching proxy, rather than blocked. If the client is a caching proxy in this case, the firewall proxy is a parent even though the child proxy does not realize it.

Organizations that pay metered rates for Internet bandwidth sometimes use multiple parent caches to send traffic over specific connections. For example, one connection might be less expensive but more congested . Low-priority requests are sent over the cheap link, while high-priority traffic goes over the expensive one. In some cases, the rates change depending on the time of day. Some caches (e.g., Squid) let you forward requests to different locations based on the current time.

only for RuBoard - do not distribute or recompile