> > Prehaps, "proxy-only" options under "cache_host" tag will
> > help for a time being.
>
> That option is currently being used between those two caches. The problem
> is that, if for whatever reason a object gets duplicated on the two caches,
> it can be there forever.
True. That's why I can only suggest it for a time being
until a better facility that is available.
> Once a really popular object is stored on both caches it will never get
> deleted. We have already seen instance where we have 25% overlap on objects
> which is not very efficient. The less overlap the better we can serve
> requests.
I guess this will be the problem that most will face
with large caches. I too have the similar problem, but
I am not too concern because I still have plenty of
harddisk to spare. But in near future, I will probably
be wondered over it.
> Stewart Forster wrote:
> > The protocol would then be.
> >
> > 1) If the source has the newest object, get that and cache it. (as usual)
> > 2) If a spouse has a newer object than me (and the source is not newer than
> > my spouse's copy), get the spouse's copy and remove my copy of the object
> > from the swap.
> > 3) If my copy is newer than everyone else's, simply return it. (as usual)
>
> I would suggest we could even simplify that by just asking any spouses
> whether they have a "FRESH" copy of the object. If so get it from the
> spouse and remove the local copy. If not do a IMS GET.
After you have grabbed the copy from spouse, do you cache it ?
If you don't, all future access will result it very high inter-cache
traffic. And if you do, there will be either two copies in each
cache, or object might migrate from caches to caches.
Maybe a two level hierarchy might help, the first been the front end
that the user access, and the higher level been the caches itself
that talk to each other or cache by domain.
*8)
Ong Beng Hui
ongbh@singnet.com.sg
...yet another day in an ISP business
...and they lived happily ever after
Received on Mon Nov 18 1996 - 03:41:47 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:34 MST