[ZODB-Dev] Re: Finding out whether an object is in the ZEO or ZODB cache.

[Toby Dickenson]

On Wednesday 21 Aug 2002 5:12 pm, Arnar Lundesgaard wrote:

> What we are trying to find is the optimal ICP based load
> balancing scheme. Currently we are benchmarking to see
> how Squid is performing with the default ICP patch first,
> with squid.conf as described in your howto.
>
> Particularly we are wondering what is smartest of
> the two options below.
>
>  1. Let Squid wait a while (say something like 0.2 s)
>     for all parents to return ICP_OP_MISS or an ICP_OP_HIT.

Yes, thats good if you have a mechanism for determining HIT or MISS

>  2. Always return ICP_OP_SECHO which makes Squid use the
>     one that replies first.

That is a good approach if you dont have such a mechanism.=20

In this case I dont think you want to be responding ICP_OP_SECHO - it is =
not=20
one of the permitted responses to ICP_OP_QUERY listed in rfc 2186.  I thi=
nk=20
unconditionally responding ICP_OP_HIT will achieve the same thing.


> > My current implementation hack looks like this.....
> >
> > I have a module-level registry which contains the URL
> > of big objects currently in memory. My big objects add
> > their url into this cache at the point where they are
> > accessed. Possibly you dont want to store URL fragments
> > rather than whole URLs..
> >
> > My ICP handler picks apart the URL by hand, using string
> > method or regular expressions, and checks whether the
> > appropriate URL fragments  are in the registry. It
> > return ICP_HIT if they are.
> >
> > It is possible to confuse this scheme by giving it
> > carefully crafted funny URLs.... That doesnt matter
> > - Its only an optimisation.
>=20
> We where wondering if using 'getPhysicalPath' would
> avoid this. We haven't given it too much thought,
> but at a first glance it looks like it could work very
> well for us.

So your are planning to use this with something that behaves like a file=20
download url - you only say ICP_OP_HIT if urls are an exact match.  ?

Yes, getPhysicalPath will work.

It would still get confused, for example if you refer to one file using t=
wo=20
different acquisition paths. This is almost certainly not a problem - jus=
t=20
something to be aware of.