Jason Healy wrote:
On Jan 5, 2010, at 7:08 PM, Chris Robertson wrote:
If the requests made to the parents has been normalized by the
url_rewrite_program, then you shouldn't need a
storeurl_rewrite_program at all.
I'm thinking about YouTube and other CDN content, where I can't
rewrite the request (since that would make the URL invalid), but I
want to map URLs to a single canonical instance. My theory is that
since this happens just before the content hits the store, it will
need to happen independently on each backend.
Correct...
However, I wasn't
quite sure how this would interact with peering (will the frontend
ask the peers for the real URL, or the storeurl_rewritten version)?
url_rewrite on the front end since it affects the entire following chain
destination.
storeurl_rewrite on the backend since its only affecting the local
instance cache storage.
- I'm using round-robin for the backend peer selection. Should I
switch to carp, or is that overkill when the instances are on the
same physical box? What advantages does carp have?
CARP routes a given request to the same parent every time. Since
cache can't be shared between instances (on the same server or not)
this can aid caching efficiency.
Sounds like an excellent reason to me. =) I'll definitely make that
change, then.
I have the idea that CARP might pass content-identical but different
YouTube URLs to different peers. Thus undermining the storeurl rewriter.
You might want to experiment and see if there are duplicated youtube
videos under CARP.
The fix for that if it happens would be to have one peer dedicated
caching source for the vids and doing storeurl_rewrite.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
Current Beta Squid 3.1.0.15
