North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: decreased caching efficiency?
Hi Christian, At 10:29 AM 19/10/2000 -0400, Christian Kuhtz wrote:
we haven't observed any real drop in overall hit-rates.Has anyone else around here noticed a decrease in caching efficiency over say, the past year or so? Seems we've seen a radical drop (order of magnitude). Seems popular sites are using more and more entirely dynamic, rapidly changing content..
providing you have sufficient disk storage provisioned with your cache, you should still be seeing 35%+ byte-hit-rates providing you have a sufficient target customer base to populate the cache. if you do have 'significant' customer-base, then a byte hit-rate around 50% isn't uncommon.
caches exist for multiple reasons --If there's indeed a reduction in efficiency, caches simply introduce more transactional latency and provide no benefit to offset cost. What do people consider reasons to be to keep caching in the network? Have caching infrastructures materialized as starting points for content distribution, or have you guys ultimately rebuilt your infrastructure to serve that specific purpose?
 to make things faster
 to save bandwidth
 to achieve more "goodput" in network transactions.
 to operate at layers-8 and 9 (filtering)
in terms of latency, you might want to look at what your caching product does on accepting a connection. many vendors' products initiate a DNS lookup in addition to that of what the user's web browser DNS lookup. if that is the case, ensuring that the user's DNS lookups go to the same caching nameservers as your caches could be a worthwhile thing.
of course, i might argue that a transparent cache shouldn't need to hold back a http request when it already knows the dst-ip-address that the flow was destined to go to, but then again, i might be considered biased.
in many cases, people significantly underestimate the effect of #3 - and it isn't easily measured. it is the effect of a "good" tcp stack cutting down end-to-end tcp retransmissions when the "last mile" hop is congested.
no comments on #4 .. probably doesn't apply to the US anyhow.