Re: [squid-users] Two squid instances based on file types? Is it good?

On Mon, 2005-02-21 at 11:33 +0100, Henrik Nordstrom wrote:
> On Mon, 21 Feb 2005, Marco Crucianelli wrote:
>
> > I was thinking about using ACL regex_url to direct avi,mp3,iso etc from
> > the small_object (front-end) squid to the big_object (back-end) squid
> > together with the directive cache_peer_access...do you think I can do it
> > this way?
>
> Yes, but you may want to also use never_direct or the same.

Why shall I use never_direct? Maybe to force the frontend squid (the one
caching web stuff) to never ask for multimedia files the origin servers,
but to redirect these "calls" to the backend squid, the one caching
multimedia stuff?!? Maybe I've a wrong idea of how squid works! I'll
bette explain myself: I thought that the flow of requests in squid was:

1) WD (WebDoc) squid receive a request for a MM (MultiMedia) file, it
doesn't have it, but it knows it has a cache_peer parent, MM squid.
2) It uses ICP to ask MM squid (its parent) if it has the requested file
3) MM squid answers it doesn't have it but it's asking to its parent
4) MM squid gets the requested file from its parent, caches it and send
to WD squid via ICP that he now has the file
5) WD squid now knows that MM squid has the file then it takes it from
MM squid, does not cahce it back (as I think to use the directive
proxy-only while definig) and then send the requested file back to the
client

Is it correct? Is there anything wrong? I mean, maybe I should use
never_direct to be sure that the WD squid asks to its parent, MM
squid?!?!?

>
> > But, what about staleness? Can I set up the refresh time in squid...with
> > which directive?!?!
>
> refresh_pattern
>
> Regards
> Henrik

Yes, refresh pattern...right! :P
Using regex in refresh_pattenr, could I match on the cache_dir (don't
think so) or could I match only on the file extension, for example?!?!
I mean: I would like to have different refresh pattern bades on
cache_dir or at least, based on file extension, thus I could keep big
multimedia files longer...

Many many thanks...once again! ;)

Marco
Received on Tue Feb 22 2005 - 05:06:08 MST