mån 2009-10-05 klockan 08:10 -0700 skrev tookers:
> Hi Henrik,
> Thanks for your reply. I'm getting TCP_MISS/200 for these particular
> requests so the file exists on the back-end,
Are you positively sure you got that on the first one? Not easy to tell
unless there is absolutely no other status code reported in the logs for
that URL. The access.log entry for the first may well be long after the
crowd.
> Squid seems unable to store the
> object in cache (quite possible due to a lack of free fd's), or possibly due
> to the high traffic volume.
Yes, both may cause Squid to not cache an object on disk. cache.log
should give indications if fd's are the problem, and also in most cases
when I/O load are the issue..
But neither lack of fds or high I/O load prevents Squid from handling
the object as cachable. That is not dependent on being able to store the
object on disk. But maybe there is glitches in the logic there... how
collapsed_forwarding behaves on cachable objects which Squid decides
should not be cached for some reason have not been tested.
> Is there any way to control the 'storm' of requests? I.e. Possibly force the
> object to cache (regardless of pragma:no-cache etc) or have some sort of
> timer / sleeper function to allow only a small number of requests, for a
> particular request, to goto the backend?
It's a tricky balance trying to address the problem from that angle.
Forcing caching of otherwise uncachable objects is one thing. This you
can do via refresh_pattern based overrides, but best way it so convince
the server to properly say that the object may be cached... but from
your description that's not the problem here.
The problem with timer/sleeper is that you then may end up with a very
long work queue of pending clients if the object never gets cachable..
Regards
Henrik
Received on Tue Oct 06 2009 - 21:49:40 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 07 2009 - 12:00:02 MDT