On Mon, Sep 07, 1998 at 09:06:22AM +1000, Anthony Baxter wrote:
> No no no, we don't want to do it _ever_. ICP going to disk will
> screw performance up utterly.
But I don't want this to occur, at least not when it doesn't now.
It will only occur, if you get a HEAD request for (say) http://blah/
in which case, the cache goes direct and puts this URL into a
short-term URL cache.
Then, if, say, 5 seconds later, the cache gets a GET http://blah/, it
looks in the `short-term URL cache', if it finds it, it will then
cache locally this object if fetched from a sibling marked
proxy-only.
In the common case, it makes no difference whatsoever, except that
all GETS then have to be checked to see whether they are in this
`short-term URL cache'. This could probably be done very cheaply.
> If it's not that common, why bother doing it? If you're not going
> to get a reasonable overall performance boost, don't bother doing
> it at all.
Quite. Further investigation shows the savings are lost in rounding
errors over a period of a month or so, so obviously not worth doing.
> And don't forget that this will add a reasonable amount of code
> complexity, for not a lot of gain - not something squid needs.
The complexity is negligible, but the probable gains even less.
I think its quite doable for many access patterns, but not worth the
effort unless more applications that using HEAD intensively, which
probably isn't going to happen because there are much better
alternatives available.
-cw
Received on Tue Jul 29 2003 - 13:15:53 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:54 MST