|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Message-Id: <4.3.2.7.2.20001020063301.01e8e1a0@203.103.99.66> Date: Fri, 20 Oct 2000 06:45:05 +1100 To: Christian Kuhtz <ck@arch.bellsouth.net> From: Lincoln Dale <ltd@interlink.com.au> Cc: nanog@merit.edu In-Reply-To: <20001019102908.P13072@ns1.arch.bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Errors-To: owner-nanog-outgoing@merit.edu Hi Christian, At 10:29 AM 19/10/2000 -0400, Christian Kuhtz wrote: >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.. we haven't observed any real drop in overall hit-rates. 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. >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? caches exist for multiple reasons -- [1] to make things faster [2] to save bandwidth [3] to achieve more "goodput" in network transactions. [4] 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. cheers, lincoln.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |