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
