Suppose that we have a cluster of 100 PC’s all with Netscape as it comes straight out of the original archive, and that all of them are started up at once. The first thing that each Netscape program will do is to load up the Netscape home page, with 100 connections for the .HTML file and 100 connections for each of the inline images.

When I last looked, the Netscape home page was 13228 bytes and it had 9 inline images: 1705; 3530; 1135; 13360; 1610; 4648; 2575; 2951 and 75 bytes, that is 44617 bytes in total, which isn’t very much but with 100 PC’s that makes 4461700 bytes (4.5Meg), which again isn’t all that much considering the capacity of today’s networks. What you should think about is that you could multiply that cluster quite a few times for the Manchester/UMIST campus alone and then again for all the other Universities; Colleges and companies around the UK, and the capacity of the network link across to the USA soon gets used up, and just for loading one page!..

When Netscape is first installed, it is configured with a memory cache of 1024K and a disk cache of 5000K. With the memory cache, the last few documents or inline images are held in memory so that repeated requests for such documents during the same session can be satisfied quickly, and in some cases animated images need a small amount of memory cache to work correctly. The disk cache is supposed to keep documents that are accessed between sessions, and it does to a limited extent, as I have noticed that there may be several copies of documents or inline images in a disk cache. Also, each user will have similar copies of certain frequently accessed pages in all the individual disk cache, which on a mainframe system such as MIDAS may mean that there are quite a few copies of documents in every users cache (such as the Netscape home page, Net search page, etc…). For this reason, on the Manchester campus, I would set the disk cache to 0 and make use of an external Proxy/Cache as detailed below.

The situation in the UK is not all that bad really, as we have the National Proxy/Cache systems at HENSA in Kent and Leeds, which would help to cut down the transatlantic WWW traffic quite a bit (if only people would make use of it…), as each WWW browser could be configured to request documents via the Proxy/Cache, which would only issue one request for the Netscape home page and its associated inline images from the USA and then relay a copy to each WWW browser.

Quite a few other JANET sites (including Manchester) are running their own Squid Proxy/Cache server rather than the Netscape Proxy/Cache used on the HENSA, and most are linked together to form a large distributed Cache system . At Manchester we have several local Proxy/Cache servers, the main one being a twin processor SUN 630MP with 1GigaByte of disk space allocated for the Cache. This is connected to the other local Proxy/Cache servers to form a mesh with each system sharing the load. The 630MP Proxy/Cache is currently handling around 800,000 requests per day and it is steadily increasing.. The new UMIST WWW server which has recently gone online is part of the mesh and is running a copy of Squid. The UMIST Proxy/Cache is configured in a slightly different way to make use of some of the more advanced features of that system (namely MultiCasting).

What you can do...

With Netscape v2/3/4 on W95 and Unix, you have 3 options:

1. No Proxy/Cache settings
2. Manual Proxy/Cache settings
3. Automatic Proxy/Cache settings

We recommend the use of the third option, as it forces the WWW browser to load up an auto configuration script when the browser is first started, and will cope with a Proxy/Cache being unavailable for whatever reason.

The script will first set the browser to use our local Proxy/Cache at MC in the case of a browser at Owens/MC and the UMIST Proxy/Cache in the case of a browser at UMIST, but if either system is down, the browser will be configured to point to an alternative system. If all the configured Proxy/Cache servers are down then the document would be requested directly. The browser will go back and check the Proxy/Cache systems periodically, and will reinstate the caching when the Proxy/Cache server again becomes available. With other WWW browsers, you would set the Proxy/Cache settings manually to point to the MC Proxy/Cache.

When a document is requested via the MC Proxy/Cache, the local cache is searched and if the document is found, then it is served from the cache. If our local Proxy/Cache does not have the document, then it will scan through all the other Proxy/Cache systems that it knows about to see if they have a copy of the document. The first one that responds will send the document to both the MC Proxy/Cache to be stored locally and to your browser. If none of the other Proxy/Cache servers respond within a specified time, then our local cache will open a connection to the remote WWW server to fetch the document. All these inter-cache queries take almost no time at all and is totally invisible to you, the user.

You can find out more from the URL:

http://wwwcache.mcc.ac.uk/Cache/

Bye for now, John