Interesting discussion - no many comments from ISPs currently using caching
regarding the effectiveness - cache hit rates or bandwidth "saved".
Any strategies for populating caches (in addition to user hits)?
Bill
Or, if you are a "Cheap Bastard (tm)", you can take a copy of Squid
(http://squid.nlanr.net), and an OS which can handle transparent proxying
(Solaris, Linux, etc), a high performance RAID, and have yourself the
equivilent. Squid is a heirarchial web cache/proxy/accelerator available
for
free.
i love squid. i use it as a nontransparent proxy and also as the web server
accelerator for all of the content we publish. squid is really cool,
especially squid-novm.
i worry a bit about the supposed proxy capabilities of these other os's. we
don't think of ourselves as idiots here when it comes to kernel programming,
and so the fact that it's taken a year of wizard level kernel muckraking to
get a system that can do thousands of simultaneous transparent sessions makes
me think that it's actually a hard problem.
we got basic kernel transparency working in an afternoon. the devil is in
the details though.
U-NET Limited - Global Transit Division
Transit for ISPs from PAIX, MaNAP or Telehouse London mailto:world@u-net.nethttp://world.u-net.net
Tel 44 1925 484444 Fax 44 1925 484466
Interesting discussion - no many comments from ISPs currently using caching
regarding the effectiveness - cache hit rates or bandwidth "saved".
Any strategies for populating caches (in addition to user hits)?
[...]
I'm not sure sure that hit rate should be the primary means of
measuring the effectiveness of an HTTP proxy/cache. As was discussed
the SF NANOG, the penalty for packet loss on connections with higher
RTTs is severe. So even if a proxy server is fetching a miss on a
path with a lower RTT than the requesting client there's still a win.
Of course, I know of no good way to measure this type of winnage.
I guess I could claim squid's ICMP RTT measurement neighbor selection
routing thing as another big win, but I'm sure it flies in the face of
all that is Decent and True with the Purists out there.
Not to interrupt a discussion by adding measured data,
but there is some collected data on MTU sizes around the net.
I believe kc has some packet statistics data online at NLANR.
Alternately, there is some @Home packet size data (from
Mike Schwartz) online in PDF format at: ftp://ftp.home.net/pub/rja/home-pkt-dist.pdf
Folks perusing the @Home data should keep in mind that nearly
all residential customers have 10baseT Ethernet access to the
Internet. So we have near zero packets larger than Ethernet MTU.
