Re: [squid-users] Caching behavior

> You mean removing it has no effect on the HIT/MISS result and status?
> You should expect just about everything to be a MISS when that QUERY
> setup is used.
>
> That whole QUERY definition is a redundant pattern.
> => the second value 'ig?' is a complex way of writing 'i'.
> => the letter 'i' by itself is a sub-pattern of all the other
> patterns
> in that ACL. So they do not add anything by their presence.
>
> Meaning ... every URL which contains the letter 'i' anywhere in its
> path
> section will *not* be cached or served from cache. 100% of your test
> URLs contain match that pattern.
>
> > no_cache deny QUERY
>
> Remove the "no_" portion of that. It was deprecated back in squid-2.2
> IIRC and has only ever confused people.
>
> > cache_mem 500 MB
> > connect_timeout 5 minutes
> > dns_retransmit_interval 5 seconds
> > dns_timeout 1 minutes
> > persistent_request_timeout 2 minutes
> > request_timeout 60 seconds
> > maximum_object_size_in_memory 2000 KB
> > maximum_object_size 800 MB
> >
> > I tried light pictures without more success
> >
> > 10.1.1.1 - - [07/Feb/2012:15:08:05 +0100] "GET
> > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg
> > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT
> > 10.1.1.1 - - [07/Feb/2012:15:08:13 +0100] "GET
> > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg
> > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT
> > 10.1.1.1 - - [07/Feb/2012:15:08:14 +0100] "GET
> > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg
> > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT
> > 10.1.1.1 - - [07/Feb/2012:15:08:15 +0100] "GET
> > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg
> > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT
> >
> > The next day, I clear my web browser's cache and retry, there is
> > TCP_HIT:NONE with only 3.0 (although there are many HIT in
> > access.log in 3.1 and 3.2). If this is not a bug then how to
> > explain such behavior ?
>
> The status is 304. Those responses do not have any body attached, so
> there is nothing for Squid to collect and cache as it passes through.
>
> The 3.0 trace shows a 200 followed by IMS revalidations from the
> client
> which get relayed through to the server.
>
> For the others it looks a bit weird, but is possible under some
> conditions. Without the sequence of full headers its impossible to
> say
> what *should* have or is happening in the other cases.
>
> For testing try using squidclient in a shell script to make a series
> of
> controlled calls. That way you can have a series of actions and know
> in
> advance what the Squid behaviour is supposed to be at each point of
> the
> test. Comparing what happens and what gets logged against the
> expected
> results.
> If you have a trace of real traffic headers you can tune the
> scripted
> calls around what those do and compare the versions under identical
> conditions.
>
> Amos
>

Thanks about urlpath_regex you are right it's ugly ...
The problem persist with or without urlpath_regex, but I think now that I have a kind of cache corrupt because all seems good with another cache.

I will format and retry
Received on Wed Feb 08 2012 - 11:18:20 MST