You are correct, this appears to be what is happening.
This breaks my initial assumptions about store.log entries, however -
instead of only logging objects either stored or removed from cache,
it's logging the "disposition" of each incoming request, showing
whether or not the request is cached or not. Is this a correct
understanding, or is it even more involved than that?
More specifically, if we use cache ACLs to declare certain objects
uncacheable, will they get logged with RELEASE lines in store.log as
well?
Also, is there a way to only log objects that are added or removed
from cache storage?
-C
On Mar 4, 2008, at 10:52 PM, Adrian Chadd wrote:
Check to see if the object is actually in cache. I bet that the
RELEASE line you're seeing is the temporary store entry that was
created purely to return the 304 message.
Adrian
On Tue, Mar 04, 2008, Chris Woodfield wrote:
Hi,
We recently added the "reload-into-ims" directive to our squid config
after noticing that a large number of queries were coming in with No-
Cache set, killing our cache efficiency. We have a relatively short
max-age set, working on the assumption that the If-Modified-Since
will
keep the unchanging content from being continually refreshed.
Looking in our store.log, however, we're seeing lots of this:
1204650204.462 RELEASE -1 FFFFFFFF 2435DD617A6A5750936E71A36D77AF8F
304 1204635071 1204057533 -1 image/jpeg -1/0 GET
http://example.com/object.jpg
I'm unsure if the meaning of this. The "RELEASE" line suggests that
the object in question was deleted from the cache store, but the 304
suggests that a 304 Not-Modified was sent to the client.
Any insights? I can't imagine that the object should be purged from
cache if a Not-Modified is returned, but I can't tell if it actually
is or not...
-C
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial
Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in
WA -
