Re: [RFC] cache architecture

tis 2012-01-24 klockan 21:51 +1300 skrev Amos Jeffries:

> So proposals for collapsables which are too large for cache_mem? or when
> "cache_mem 0"?

collapsed forwarding requires the ability of an early cache hit, that is
a cache hit on an object currently being stored. This is also an useful
optimization for many other traffic patterns, collapsed forwarding is
just an extreme case of it allowing weak hits even before it's known the
response will be cacheable.

There is also some hacks in collapsed forwarding to track IMS refreshes.

> > non-shared cache. Please keep in mind that any non-shared cache would
> > violate HTTP in an SMP case.
>
> You have yet to convince me that the behavious *is* a violation. Yes the
> objects coming back are not identical to the pattern of a traditional
> Squid. But the new pattern is still within HTTP semantics IMO, in the
> same way that two proxies on anycast dont violate HTTP. The cases
> presented so far have been about side effects of already bad behaviour
> getting worse, or bad testing assumptions.

There is some rules on caches always returning the latest known
representation. But that rule is pretty unenforceable in any distributed
cache.

non-shared caches in SMP is just an extreme case of distributed cache.

> > In-transit space does not need to be shared (but it is separate from
> > caching as discussed above).

But see above.

> > Linear fileno space prevents many optimizations. I would not require it.
> > FWIW, Rock store does not use linear fileno space.
>
> Okay. So something else. A non-linear map or tree of tri-state values
> (quad-state, whatever). Used, open, unchecked.

fileno is really a cache_dir internal property. main code should not
care about what fileno is at all.

and if we kill the central index then main code should not even see it.

Regards
Henrik
Received on Tue Jan 24 2012 - 16:10:11 MST