North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: decreased caching efficiency?
- From: Lincoln Dale
- Date: Fri Oct 20 08:51:53 2000
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
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
 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.