Re: proxy caching

G'day Michael!

On Jun 30, 11:10am, Michael Mansour wrote:
> Subject: proxy caching
>
> I'm hoping someone can help in my understanding of the way Squid works.
> I'm currently questioning whether Squid is actually reading from my
> cached drive.

You can look either access.log or more specifically store.log, to see what is
happening to the requests passing through the cache. You may even wish to run
the logfile analysis scripts that are provided on the Squid web page. This will
very neatly summerise what happened to the cache for the given period. I run
these scripts from cron every 24hrs.

If you have emulate_httpd_log on you will need to run the scripts with a -h or
inside the scripts, set $HTTPDFormat = 1; The default is 0.

> The primary box I use for caching is on shell.gnxs.com.au, this is on my
> local linux box, and is where I want all web requests brought to if the
> pages are cached here, after that, it should check the neighbors. 98% of
> all clients are located on bbs.npgx.com.au, which is connected via
> ethernet lan to the shell.gnxs.com.au linux box.

Why not run Squid on bbs.gnxs.com.au? Is it not a UNIX box? Obviously this
would save have to travell to shell.gnxs all the time.

> My setup follows (the options I show below are what I've actually set, all
> the rest of the options are on default values):
>
> I've currently setup two neighbors (I don't understand the difference
> between parents and neighbors):

When a reuest is made by Squid, a 'ping' is sent to all the parents, neighbours
and if you have source_ping on to the original site(the defualt is off, but
that is fine).

The first machine that replies with a HIT will service the request. If you
compiled with -DUDP_HIT_WITH_OBJ, smaller sized files will actually be returned
with the HIT reply, otherwise a TCP connection will be made to the HIT machine.

If no machine returns a HIT, the request is passed on to the parent machine to
fullfill. If no machine has replied within neighour_timeout, you go direct to
the original site.

Certain types of requests are not sent to the hierarchy, such as URL's with
cgi-bin or ? in them.

> cache_host abyss.aiss.net.au neighbor 3128 3130

I can't do a DNS on this host. Is it 'closer' then geko? Is the cache of an
equal or greater size than yours?

> cache_host www.geko.net.au neighbor 3128 3130

Seeing as geko provides you network feed, I would make them my parent. That
will boost the size of the geko cache, which will also assist their other
clients, and then also you inturn.

With this cuurent setup, if your machine services the request, you still have
to go through the geko network.

After running the cache for a few 'typical' days, the information from Cache
Server List obtained from the cachemgr.cgi, will help you to 'see' what is
happening, and if either machine is being of any use.

> My local domain I've set is:
>
> local_domain shell.gnxs.com.au gnxs.com.au

shell.gnxs.com.au is under gnxs.com.au, so you only need the later.

> neighbor_timeout 8

Depending on just how slow your network connection is, the default of 2 is
fine. Just ping the neighbour/parent machines to get a feel for 'how far away'
they are. At first glance, this is probably why you are seeing such degraded
performance. Change it back to 2 and see if things improve.

> cache_mem 16
> cache_swap 170

Always the more the merrier. Store.log and the information from the
cachemgr.cgi will help you to see if you could do with more or less.

> Considering the link here is not superfast, are those settings
> appropriate? Because when looking in my hierarchy.log file, I always seem
> to notice that although I know the pages are cached here, it never logs a
> hit here but only on neighbors.

HITS on your cache are not logged to hierarchy.log. If there is a HIT from your
cache, there is no need to send the request to the hierarchy. Your Squid just
servers the file straight away. To see your HITS, lok in access.log, or run the
logfile analysis scripts off the Squid web page.

> The proxy used to run superfast, but nowadays is very slow.

See comment about neighbour_timeout above. It could also be that your machine
is starting to swap out or lacking some other resource.

Hope this helps.

Ed

-- 
Ed Knowles aka Jasper				Phone : +61 2 385 4962
E-mail: ed@fatboy.geog.unsw.edu.au		Fax   : +61 2 313 7878
                  This space intentionally left blank.