Fili wrote:
Hello Squid-people!
On a network that I'm administering there is a weird ongoing problem.
The basic setup is as follows:
Squid-cache -> Apache webnodes -> NFS Fileserver
Strangly enough on some of the website's embedded mp3 files are often
cut short to a mere 2sec file (while they are minutes long). When
performing a hard refresh, the file usually can be played as normal.
I've tried on several operating systems, using different mp3 files,
browsers, ISP connections and embedding techniques. One time it works
the other time it doesn't, it seems to be totally unpredictable.
This all leads me to think that maybe Squid has something to do with it.
When looking in the cache-spool the mp3-files always seem to have the
right filesize (this is hard to check for certain).
Check the access.log column which lists how many bytes of reply object
sent to the client on each request.
If these are wildly smaller than the requested file size on Apache then
look closer at the cached object size (squidclient or cachemgr.cgi can
show the list)
The cache file size will be around 1-2KB larger than the MP3 file
itself. Which should not be much
There also is enough diskspace and inodes available on the caching server.
As a test I've instructed squid to prevent the caching of mp3-files all
together by using this refresh_pattern:
refresh_pattern -i \.mp3 0 0% 0
Won't work. refresh_pattern determines how long an object gets to stay
in cache. _after_ its already been stored there.
Use "cache deny XX" to prevent things entering the cache.
and also a .htaccess on a test-domain with these lines:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 2 hours"
ExpiresByType audio/mpeg "access"
ExpiresByType audio/mp3 "access"
</IfModule>
This did the trick in never swapping out, however the problem did not go
away.
Those apache lines tell Squid not to cache the object at all.
It's likely a transfer problem then...
Check the HTTP headers sent by Apache. (www.redbot.org) If there are no
explicit file sizes (Content-Length) header and Squid set with reply
object max limits things may get truncated without notification.
I find it very hard to debug this issue and have no idea where to look
next.
Maybe I'm on the wrong track in thicking that Squid is involved.
Maybe yes, maybe no. It's good to know for certain either way.
I'm inclined to think its the NFS filesystem sometimes not giving Apache
all the data. The same check of apache access.log as I mention for the
squid one above should tel you if its that.
Does anybody have experienced something similar?
We get infrequent reports of jitter and re-buffering in playback but
your the first with corrupted files in a long time.
Or maybe has a suggestion as to where to look next?
see above.
Thanks in advance,
Fili
==Some version information==
Debian Lenny
Squid3 3.0.STABLE8-3+lenny
Apache 2.2.9-10+lenny4
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE19
Current Beta Squid 3.1.0.13
