The Squid distribution includes a CGI utility called cachemgr.cgi which can be used to view squid statistics with a web browser. This document has a section devoted to cachemgr.cgi usage which you should consult for more information.
sort -r -n +4 -5 access.log | awk '{print $5, $7}' | head -25
One way is to add -z to the command line.
Another, perhaps easier way is to simply remove the log
file found in the first cache_dir directory.
The RealPlayer (and RealPlayer Plus) manual states:
Use HTTP Only
Select this option if you are behind a firewall and cannot
receive data through TCP. All data will be streamed through
HTTP.
Note: You may not be able to receive some content if you select
this option.
Again, from the documentation:
RealPlayer 4.0 identifies itself to the firewall when making a
request for content to a RealServer. The following string is
attached to any URL that the Player requests using HTTP GET:
/SmpDsBhgRl
Thus, to identify an HTTP GET request from the RealPlayer, look
for:
http://[^/]+/SmpDsBhgRl
The Player can also be identified by the mime type in a POST to
the RealServer. The RealPlayer POST has the following mime
type:
"application/x-pncmd"
Note that the first request is a POST, and the second has a '?' in the URL, so standard Squid configurations would treat it as non-cacheable. It also looks rather ``magic.''
HTTP is an alternative delivery mechanism introduced with version 3 players, and it allows a reasonable approximation to ``streaming'' data - that is playing it as you receive it. For more details, see their notes on HTTP Pseudo-Streaming.
It isn't available in the general case: only if someone has made the realaudio file available via an HTTP server, or they're using a version 4 server, they've switched it on, and you're using a version 4 client. If someone has made the file available via their HTTP server, then it'll be cacheable. Otherwise, it won't be (as far as we can tell.)
The more common RealAudio link connects via their own pnm: method and is transferred using their proprietary protocol (via TCP or UDP) and not using HTTP. It can't be cached nor proxied by Squid, and requires something such as the simple proxy that Progressive Networks themselves have made available, if you're in a firewall/no direct route situation. Their product does not cache (and I don't know of any software available that does.)
Some confusion arises because there is also a configuration option to use an
HTTP proxy (such as Squid) with the Realaudio/RealVideo players. This is
because the players can fetch the ``.ram'' file that contains the pnm:
reference for the audio/video stream. They fetch that .ram file from an HTTP
server, using HTTP.
--Rodney van den Oever <roever@nse.simac.nl>
--James R Grinter <jrg@blodwen.demon.co.uk>
A purge feature was added to Squid-1.1.6. It only allowed you
to purge HTTP objects until Squid-1.1.11. Squid does not allow
you to purge objects unless it is configured with access controls
in squid.conf. First you must add something like
acl PURGE method purge
acl localhost src 127.0.0.1
http_access allow purge localhost
http_access deny purge
The above only allows purge requests which come from the local host and
denies all other purge requests.
To purge an object, you can use the client program:
client -m PURGE http://www.miscreant.com/
If the purge was successful, you will see a ``200 OK'' response:
HTTP/1.0 200 OK
Date: Thu, 17 Jul 1997 16:03:32 GMT
Server: Squid/1.1.14
If the object was not found in the cache, you will see a ``404 Not Found''
response:
HTTP/1.0 404 Not Found
Date: Thu, 17 Jul 1997 16:03:22 GMT
Server: Squid/1.1.14
As of version 1.1.9, Squid is able to utilize ICMP Round-Trip-Time (RTT) measurements to select the optimal location to forward a cache miss. Previously, cache misses would be forwarded to the parent cache which returned the first ICP reply message. These were logged with FIRST_PARENT_MISS in the access.log file. Now we can select the parent which is closest (RTT-wise) to the origin server.
It is more important that your parent caches enable the ICMP features. If you are acting as a parent, then you may want to enable ICMP on your cache. Also, if your cache makes RTT measurements, it will fetch objects directly if your cache is closer than any of the parents.
If you want your Squid cache to measure RTT's to origin servers, Squid must be compiled with the USE_ICMP option. This is easily accomplished by uncommenting "-DUSE_ICMP=1" in src/Makefile and/or src/Makefile.in.
An external program called pinger is responsible for sending and
receiving ICMP packets. It must run with root privileges. After
Squid has been compiled, the pinger program must be installed
separately. A special Makefile target will install pinger with
appropriate permissions.
% make install
% su
# make install-pinger
There are three configuration file options for tuning the
measurement database on your cache. netdb_low and netdb_high
specify high and low water marks for keeping the database to a
certain size (e.g. just like with the IP cache). The netdb_ttl
option specifies the minimum rate for pinging a site. If
netdb_ttl is set to 300 seconds (5 minutes) then an ICMP packet
will not be sent to the same site more than once every five
minutes. Note that a site is only pinged when an HTTP request for
the site is received.
Another option, minimum_direct_hops can be used to try finding servers which are close to your cache. If the measured hop count to the origin server is less than or equal to minimum_direct_hops, the request will be forwarded directly to the origin server.
Your parent caches can be asked to include the RTT measurements
in their ICP replies. To do this, you must enable query_icmp
in your config file:
query_icmp on
This causes a flag to be set in your outgoing ICP queries.
If your parent caches return ICMP RTT measurements then
the eighth column of your access.log will have lines
similar to:
CLOSEST_PARENT_MISS/it.cache.nlanr.net
In this case, it means that it.cache.nlanr.net returned
the lowest RTT to the origin server. If your cache measured
a lower RTT than any of the parents, the request will
be logged with
CLOSEST_DIRECT/www.sample.com
The measurement database can be viewed from the cachemgr by selecting "Network Probe Database." Hostnames are aggregated into /24 networks. All measurements made are averaged over time. Measurements are made to specific hosts, taken from the URLs of HTTP requests. The recv and sent fields are the number of ICMP packets sent and received. At this time they are only informational.
A typical database entry looks something like this:
Network recv/sent RTT Hops Hostnames
192.41.10.0 20/ 21 82.3 6.0 www.jisedu.org www.dozo.com
bo.cache.nlanr.net 42.0 7.0
uc.cache.nlanr.net 48.0 10.0
pb.cache.nlanr.net 55.0 10.0
it.cache.nlanr.net 185.0 13.0
This means we have sent 21 pings to both www.jisedu.org and
www.dozo.com. The average RTT is 82.3 milliseconds. The
next four lines show the measured values from our parent
caches. Since bo.cache.nlanr.net has the lowest RTT,
it would be selected as the location to forward a request
for a www.jisedu.org or www.dozo.com URL.
When Squid receives an If-Modified-Since request, it will not forward the request unless the object needs to be refreshed according to the refresh_pattern rules. If the request does need to be refreshed, then it will be logged as TCP_REFRESH_HIT or TCP_REFRESH_MISS.
If the request is not forwarded, Squid replies to the IMS request according to the object in its cache. If the modification times are the same, then Squid returns TCP_IMS_HIT. If the modification times are different, then Squid returns TCP_IMS_MISS. In most cases, the cached object will not have changed, so the result is TCP_IMS_HIT. Squid will only return TCP_IMS_MISS if some other client causes a newer version of the object to be pulled into the cache.