Notes

To verify that you are receiving objects properly from the SkyCache feed, look in the HTTP logs and verify that objects that are requested from the SkyCache CA are being retrieved with a retrieval method of SIBLING_HIT. If objects are being retrieved directly and not via the SkyCache CA, you will want to make sure your peering with the SkyCache CA is setup properly.

Statistics about hit rates and performance within the web management interface will be tainted by the SkyCache feed, due to the method involved in getting objects into the cache. Counters for hit rate percentages in particular will appear much lower than their actual value. To get accurate numbers for cache performance, logs will need to be pulled from the server and post-processed with connections from the SkyCache CA removed.

If the Cobalt cache becomes slow responding to client requests while receiving a SkyCache feed, you may need to add additional Cobalt caches to respond to client requests. In a 'SkyCache Cache' configuration, one Cobalt cache would respond only to client requests, while another would only take the SkyCache feed.

Example SkyCache Cache Configuration:

Using two CacheRaqs, designate one to take the SkyCache feed and another as a client visible cache. Peer the client cache to the SkyCache cache via a ICP sibling relationship, so that when the client cache sees a request for an object which it does not have on disk, it will query the upstream (SkyCache fed) cache for the object. In this scenario, the SkyCache cache only deals with the incoming SkyCache feed and ICP requests from client cache servers, which should effectively distribute the load.

Resources

Cobalt Networks web site: http://www.cobaltnet.com

Download other versions of this document: TEXT  PDF