Neil Harkins wrote:
hi. this might belong on squid-dev, but figure i'll try here first. squid doesn't know if an object is even cacheable until it gets the headers back from origin, thus collapsed forwarding seems to impair performance of non-cacheable content, by blocking what will have to be a separate request anyway. most site administrators know what's cacheable or not on their site, and could craft regex to differentiate thus collapsed_forwarding being acl-based would be extremely beneficial, but it appears to be global on/off today. is this conclusion correct? are there any architectural reasons why it would be a bad idea?
Well, most administrator set Cache_Control page headers much more easily than embedding regex patterns in URL. Which work on every cache worldwide instead of just the local reverse-proxy (if any).
Collapsed-forwarding is external to the cache. Just because the local admin has not chosen (legal or policy Reasons) to store large .divx files in local cache, does not mean there is no benefit from collapsed-forwarding on those items.
another way to optimize it would be to restrict it to revalidations only, not misses. then it would only apply to what is known to have been cachable.
There is a large subset of multicast-objects which are non-cacheable-objects. The above is one example, true multicast streaming audio/video is another. Torrents and Onions, yet another, While Squid does not support those yet they are currently under discussion.
Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
