Re: thoughts on memory usage...

In message <Pine.LNX.3.96.970821145832.2444J-100000@typhaon.ucs.uwa.edu.au>, Da
vid Luyer writes:
> And then the rules change. Rule 6 is no more. The URLs would have to be
> checked against the rules on every config file reload... which means
> storing them in the log file and frequent re-reading. I don't know if we
> need to look at the refresh rules except when doing a request and checking
> if an object is valid tho... an LRU-like technique should be fine for
> purging cache objects. And then the URL isn't needed at all.

pish tosh. How often do people change their rules anyway. :)

There is probably still a need to change expiry based on url; i.e. for
'fixing' some broken servers that don't hand out decent meta-data.

Hmm. Or instead of tagging them with the rule number, you tag them
with the rule values. (there's only 3 active numbers for each rule).
 
> >In for a penny, in for a pound. If you trust MD5, which bother sending
> >the entire URL over in the ICP? that's just a waste of bandwidth and
> >CPU time. Just send over the md5 signature.... half a :)
>
> Well, agreed. A new ICP query which talked with MD5/HSA sum instead of
> URL to compatible caches would work. But recieving an old ICP query you
> have to do the MD5/HSA hash (cheap on small strings) - not a problem. The
> point I was making was that I wouldn't want to check an on-disk URL for
> every ICP query.

Nod. And given that you more likely to win lotto 3 consecutive times,
than you are to get duplicate URL's......
 
> >Still not sure why you need the URLs that much. why not write them to
> >a seperate log? if reindexing is an oddity, then you're not really
> >fussed about the speed....
>
> Well, because the seperate log gets corrupt, runs out of disk space, gets
> deleted, .... Keeping them on the first line of the swap files would mean
> you can construct whatever you want out of just the cache files, survive
> over disk re-arrangement and loss of log files due to running out of disk
> space, etc. And because it wouldn't really cost anything in runtime or
> disk usage except where it pushes an item into a new block; the only cost
> is moving over.

But nothing actually uses the reverse. You just write it out for the
same reason you write out the logs. Someone else might be interested,
but squid isn't.

Michael.
Received on Tue Jul 29 2003 - 13:15:42 MDT