[squid-users] no_cache and Process Filedescriptors Allocation menu don't agree

Hello,

I am wondering both why the Process Filedescriptor Allocation table logs
file types set to "no_cache" and whether Nread and Nwrite means Number FD's
or Bytes read and written or something else. If it is Bytes, it does not
seem to be accurate since the file is 5+MB.

Short background (the why): Our Squid server is 3-4 times slower than
surfing directly to the internet. From our reading and using the Cachmgr
cgi, it seems
that much of our bottleneck is I/O and much of that is streaming audio/video
(users listening to internet radio). The server Ultra 60 Sun server running
Solaris 8
only has one internal SCSI controller that runs the two internal disks: they
are mirrored using disksuite.
Squid version is: Squid Cache: Version 2.5.STABLE1-20030307
configure
options: --enable-dlmalloc --enable-async-io --enable-storeio=aufs,diskd,uf
s --enable-removal-policies=heap,lru --enable-delay-pools
--disable-icmp --disable-ident --enable-cachemgr-hostname=ourproxy

Using the Cachemgr.cgi script's "Process Filedescriptor Allocation" printout
we can see many users doing streaming media (.asx, .wmv, etc.). We can't
arbitrarily block these until a policy has been developed and rolled out to
each and every user. So in the meantime I want to not cache the streaming
media to reduce disk writes. Everyone is listening to different (radio)
stations and since the content changes, our feeling is "why cache it?"
Also we figure that this will alleviate some of the I/O contention for
writing to internal the internal disk. If this reasoning is wrong-headed,
please advise. We plan on rolling out delay pools soon but are trying one
thing at a time.

So my question is: is the server no longer caching, now that I have added
these acl/no_cache directives to the squid.conf file:
      acl zipfiles urlpath_regex -i \.zip$ \.asf$ \.tar$ \.asx$ \.wmv$
\.mpg$ \.rm$ \.mov$ \.iso$ \.mpeg$
      no_cache deny zipfiles

From reading the FAQ and the mailing list via groups.google, I think the
answer would be YES it's no longer caching. cache.log has nothing in it
(good sign) except my own accesses to the cachemgr.cgi and access.log logs
this line once the transfer is completed: 1048619816.535 595467 192.168.1.4
TCP_MISS/206 3283803 GET http://205.225.141.21/BerkeleyDB.tar -
DIRECT/205.225.141.21 application/x-tar

 However the Process Filedescriptor Allocation table still actively shows
the file and the Nread and Nwrite columns continue growing as the file
continues downloading. The numbers increment as the file is further
downloaded though they don't match the bytes. Since the ratio is about 1.6:1
(bytes in BerkeleyDB.tar to the Nread or Nwrite) I am wondering what the
number could represent. It's not bytes and I can't believe there is 1.6 FD
per byte (that wouldn't be efficient). So what are Nread and Nwrite
supposed to represent?

Lastly, since the idea of enabling no_cache is to not have any additional
disk reads/writes I am wondering why this is still logging in the sub-menu?
Can anyone tell me why and/or if I am doing something wrong or making
incorrect assumptions?

thanks,

Adam

Here is the Cachemgr.cgi Process Filedescriptor Allocation just prior to the
download finishing:
Active file descriptors:
File Type Tout Nread * Nwrite * Remote Address Description
---- ------ ---- -------- -------- --------------------- -------------------
-----------
   3 Log 0 0 0
/logs/cache.log
   6 Socket 0 1291 412 .0 DNS Socket
   7 File 0 0 347721
/logs/access.log
   8 Pipe 0 0 0 unlinkd ->
squid
   9 Socket 0 0* 0 .0 HTTP Socket
  10 Socket 0 0* 0 .0 HTTP Socket
  11 Pipe 0 0 0 squid ->
unlinkd
  12 Socket 0 0* 0 .0 HTTP Socket
  13 Socket 0 0* 0 .0 HTTP Socket
  14 File 0 0 192
/cache/swap.state
  15 File 0 0 192
/cache2/swap.state
  16 Socket 1430 572* 3254047 192.168.1.4.2028
http://extern.site.com/BerkeleyDB.tar
  17 Socket 4 3254043* 1310 extern.site.com.80
http://extern.site.com/BerkeleyDB.tar
  18 Socket 1440 162* 0 192.168.1.4.53586
cache_object://squid.mydom.com/filedescriptors
  24 Pipe 0 0* 0 async-io
completetion event: main
  25 Pipe 0 0 0 async-io
completetion event: threads
Received on Tue Mar 25 2003 - 14:17:44 MST