Re: [squid-users] storeid and revalidation

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 01 Mar 2013 22:26:28 +1300

On 1/03/2013 6:42 p.m., jiluspo wrote:
> Good day,
>
> If I understand correctly. Storied was a port from storeurl with
> some modification to fit to squid3. Therefore same with storeurl issue. We
> found the content in cache and hit but we cannot revalidate(if url is
> mismatch but storied matched) then content be freed/deleted and store the
> new content from revalidation will be stored.(im new to squid3)
>
> Assuming we have 2 CDN servers serving same content but different
> Etag and modified date. Therefore when using storied we have force them to
> ignore-reload and others that makes content revalidate? Or should storeid be
> added to IMS codes for revalidation...

Thank you for bringing this up. Your point about revalidation with
storeId is a good one. We do not as yet have a good solution, ideas are
welcome. But using teh ignore-* and override-* options is probably not a
good option to jump to yet without a proper analysis.

Given any two objects with:
  - different URLs (version control label in HTTP/1.0)
  - different modification times (version control label in HTTP/1.0)
  - different ETag (version control label in HTTP/1.1)

The implication is very strong that they are different objects. How do
you *know* they are actually identical? I mean really identical - down
to the binary level where Range requests can take a set of bytes from
each and interleave them without corrupting the object, because there
are clients out there which will do exactly that.

If the ETag or Last-Modified has changed, as in your specific example,
the object has probably changed at the binary level elsewhere as well.
Squid would perform this same re-fetch even if you disabled stroreId and
had the two URLs identical in the first place. The best solution is to
synchronise the CDNs such that they are consistent in the objects they
are sending out, and accepting one public URL for each unique object.
That way storeId is not needed in the first place and your clients can
all benefit from the speed increase, not just your internal proxy
installation.

PS. I suggest you look at replication tools like rsync to mirror data
between your CDNs better. The Last-Modified timestamp has no need to
change between CDNs. ETag creation algorithm should also be
synchronised, but that is an internal matter for how you generate them.

Amos
Received on Fri Mar 01 2013 - 09:26:42 MST

This archive was generated by hypermail 2.2.0 : Fri Mar 01 2013 - 12:00:04 MST