[98620] in North American Network Operators' Group
Re: Content Delivery Networks
daemon@ATHENA.MIT.EDU (=?iso-8859-1?Q?Bj=F8rn_Mork?=)
Tue Aug 14 07:22:20 2007
From: =?iso-8859-1?Q?Bj=F8rn_Mork?= <bjorn@mork.no>
To: "Chris L. Morrow" <christopher.morrow@verizonbusiness.com>
Cc: Rodney Joffe <rjoffe@centergate.com>, Florian Weimer <fweimer@bfk.de>,
NANOG <nanog@merit.edu>
Date: Tue, 14 Aug 2007 11:24:19 +0200
In-Reply-To: <Pine.GSO.4.58.0708131707220.21180@marvin.argfrp.us.uu.net>
(Chris L. Morrow's message of "Mon, 13 Aug 2007 17:10:11 +0000 (GMT)")
Errors-To: owner-nanog@merit.edu
"Chris L. Morrow" <christopher.morrow@verizonbusiness.com> writes:
> that sets a lower-bar on TTL in the nscd cache -
>
> (from the manpage for nscd.con)
>
> positive-time-to-live cachename value
> Sets the time-to-live for positive entries (successful
> queries) in the specified cache. value is in integer
> seconds. Larger values increase cache hit rates and
> reduce mean response times, but increase problems with
> cache coherence. Note that sites that push (update)
> NIS maps nightly can set the value to be the
> equivalent of 12 hours or more with very good perfor-
> mance implications.
>
>
> This is still a client issue as, hopefully, the cache-resolvers don't
> funnel their business through nscd save when applications on them need
> lookups... (things like ping/telnet/traceroute/blah)
nscd may represent a problem if the application in question is a
http-proxy without it's own resolver. There's also a number of
more-or-less broken http-proxies doing their own resolver caching
regardless of actual TTL.
Such applications represent a problem wrt any DNS-based load balancing,
including CDNs, since they can serve a large number of end-users,
redirecting them to the "wrong" address long after the TTL should have
expired.
Bj=F8rn
