Alex Rousskov wrote:
> Any digest generation scheme is suboptimal.
True, but the current is quite suboptimal given what can be done with
digests.
Major known problem with digest generation in 2.2.STABLE4 is that it
bases the decision on the default refresh pattern.
Fix: remake the timestamps kept in the in-core StoreEntry to only
include the derived timestam "Fresh until". All the other timestamps can
be kept on disk, and "Fresh until" can be recalculated each time the
object is referenced, as I suggested earlier.
A related problem is that it includes the LRU tail even if it can be
expected that these objects will be removed from the cache during the
digests lifetime.
Fix: Skip the LRU tail of objects equal to slightly more than what was
removed during the last digests lifetime.
(the tail problem can be expected to be negligable on any reasonably
sized cache)
> Note that N false hits would reduce average persistent connection
> length by the factor of (N+1). For example, one false hit in the
> "middle" of a persistent connection will effectively half persistent
> connection length. Hence even a super-optimized digest generation scheme
> (http://hem.passagen.se/hno/squid/squid-2.7.DEVEL2.optimal.digest.patch)
> would have a drastic effect on average pconn length.
Would have a false hit ratio, yes. Effect on pconn length is another
issue as seen below.
> > False hits is considered by Squid as an error, and currently any
> > errors causes the connection to be non-persistent.
>
> Right. Looks like to improve pconns life time we need to build, a
> close-or-not-to-close-on-error decision table. For example, false hit does
> not have to close a connection to a valid peer, while request parsing error
> should close. More exceptions. Sigh.
Right.
/Henrik
Received on Tue Jul 29 2003 - 13:15:59 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:16 MST