Ever since the earliest days of the PC we have accepted that caching is a "good thing". Processors have cache, high-performance disk controllers have cache, network operating systems use system RAM for their cache – all designed to get data closer to the requesting device or user.

The concept is simple – data which has been requested recently or is requested frequently is likely to be needed again soon. If we store it temporarily in some form of local high-speed medium (such as memory) then if the data is required again we have it to hand (rather than having to go back to the original storage place to retrieve it) and can supply it to the client almost instantly. More advanced cache engines can take things further by attempting to predict the next piece of data that will be requested and "pipelining" that data into cache as well as optimising the way that cache contents are refreshed, maintained and deleted. The result is a huge perceived performance increase for the end user.

Given that we accept the usefulness of the cache in general then, it was surely only a matter of time before we started to see a whole new industry based around the need for caching that most troublesome, inconsistent and downright sluggish data source – the Internet.

Web traffic is growing faster than almost any other type of data traffic over the corporate network as more and more users take advantage of this huge information resource, and more and more applications become Web-enabled in some way. Unlike previous generations of computing where data traffic could be predicted and controlled to a certain extent, the Web model results all too often in completely random and unpredictable data patterns, with successive mouse clicks accessing data on a server in the next room followed by a server on the other side of the world.

It is this very unpredictability that leads some people to brand Web caching as a waste of time. Every user is an individual and will browse the Web for different items, surely? And how likely is it that users will go back to the same page time and time again? This may happen in certain cases, such as when a user accesses the same page for stock quotes several times a day, but surely not in the sort of quantities that would make a cache worthwhile?

As it happens, it is not difficult to blow such objections out of the water. Groups of users in the same industry, and certainly in the same company, will indeed tend to visit the same sites and pages. Even where users go off on their own in to "uncharted territory", caching is still worthwhile owing to that way objects are used and reused on Web pages. So even if a user does not actually visit the same page time and again, he or she is still usually forced to retrieve the same objects - such as corporate logo images or menu items - over and over again throughout a browsing session. Where an object is used on every page in a Web site, for instance, caching locally ensures that this is not retrieved time after time.

Some may point to the local cache employed by the users own browser as a way around this. Unfortunately, this cache cannot be shared amongst several users on a network, and whilst some improvements may be seen in environments with small numbers of users (any form of caching being better than none), a number of heavy users will still cause duplication of data retrieved over the corporate Internet link. At the end of the day, such duplication will increase the WAN traffic in a company, pushing up costs and reducing performance from the end user’s perspective.

Why is caching needed on the Web? Anyone who has tried to make extensive use of the Internet will probably be able to give you a resounding answer – because it’s slow! But it is not all about pure bandwidth. There are other factors at work too.

The first is about how Web pages are actually constructed – as a number of discrete objects. Every item on a Web page – be it a logo, menu button, picture or block of text – is a separate object. This requires a highly complex set of requests and responses between client and Web server in order to correctly display a complete Web page in the browser. Round trips between client and server are required for the initial DNS lookup, opening the TCP connection, and retrieving the Web page details. After that, two round trips are required for each and every object on the page.

Further delays are caused by the fact that Web browsers can only fetch these objects in groups of four at a time. With some poorly designed Web pages containing tens or even hundreds of small objects, you can see that more time is spent requesting and retrieving objects than on actual "data" transfer.

One other limiting factor as far as the Web is concerned is the speed of light! Due to the distances between client and Web server – particularly when accessing servers on the other side of the world – it can take seconds just to propagate the requests and responses for a single page over optical fibre. The speed of light in a vacuum is around 180,000 miles/second (300,000 Km/sec). In fibre or copper cable, data can travel at around 60 per cent of the speed of light, just over 100,000 m/sec or 180,000 Km/sec.

Now imagine a browser in London requesting a page from a server in Atlanta, over 5000 miles away. If that page has 25 objects on it, then at least 50 round trips are required, meaning the data has to travel all of 500,000 miles before the browser receives the whole of the page. Even if the Internet was free of all other traffic and the server responded immediately, it would still take a minimum of five seconds to retrieve that data.

The only solution to the speed of light problem is to bring as much data close to the user as possible, by deploying network caching. Amazing to think, though, that the fastest thing known to man is just too slow to keep up with the demands of the Internet!

Of course, caching software – such as Squid, which runs on Unix boxes – has been around for some time now, though in its native form it is looking a little long in the tooth. What is different about the CacheFlow product is that it follows the current trend of the "network appliance", in offering a complete hardware and software "black box" solution – just plug it in and forget it!

The hardware is based around a fairly standard Intel platform. Inside the CacheFlow 100 box is a standard Intel motherboard with a Pentium processor, 2GB disk, 128MB of RAM (other units in the range offer larger variants of these) and an auto-sensing 10/100 Ethernet card. The striking black and yellow front panel sports only a reset switch and LED indicators for power, disk activity and network activity. The rear panel is similarly unadorned, with only a serial interface and the aforementioned Ethernet port.

Most of the memory and disk space is devoted to caching, owing to the fact that CacheFlow has written its own caching operating system – CacheOS - from the ground up rather than rely on software sitting on top of general purpose OS such as NT or Unix. CacheOS is thus optimised for speed of response above all else, combining features such as Active Caching, Object Pipelining and DNS Caching with a highly efficient storage system. One example of the latter is that CacheOS does not worry about File Allocation Tables or writing data in "blocks" to disk – instead it streams data in the most efficient manner possible to the disk, keeping related items together in a sequential manner for rapid retrieval.

Active Caching ensures that the CacheFlow device does not wait until data is requested from the cache before enquiring whether that data is "stale". Instead, it uses an intelligent algorithm to constantly analyse the cache contents and determine which items are most likely to be requested again, and these items are kept up to date in the background when the cache is not busy. This drastically reduces the time required to deliver these objects to the clients.

Object pipelining ensures that the CacheFlow 100 will retrieve all objects associated with a web page in one hit when the page is first accessed, rather than in small groups in the manner of a standard Web browser. This means that as the browser requests objects on a page, they are already in cache, thus speeding up data delivery on pages which were not even in cache when first requested.

Installation is simply a matter of plugging in the device, connecting a PC to the serial port to assign an IP address, netmask, default gateway and DNS server, and away you go. From that point onwards, all management is performed via the Java Web browser interface. I’m not usually a fan of Java management interfaces – they can be slow and clunky and throw up all sorts of browser incompatibilities. I was pleased to see that the CacheFlow interface caused none of these problems, and proved very easy to use.

Using this utility, it is possible to set various parameters regarding the operation of the unit, including the way the caching engine itself works (though all the defaults are perfectly adequate for day to day use).

In addition to that, you can gain access to all the system documentation and a wide range of graphical statistics screens regarding cache efficiency, cache contents, current user sessions, and so forth. One feature that is worth mentioning is the ability to create direct addresses (sites that should not be processed by the cache) and deny addresses. This latter feature allows the administrator to perform some rudimentary content filtering, denying access to non-productive or objectionable sites, perhaps.

The CacheFlow device can be placed anywhere on the corporate LAN, and there are two main methods of use – proxy or transparent. CacheFlow 100 can function as a standard Web proxy, although this requires touching every client in order to configure the Web browser to point to the Web cache. This can be automated to a certain extent, of course, using Proxy Auto-Configuration (PAC) files.

Transparent caching makes it easier to deploy the CacheFlow 100 on the network, since all that is required for a router or load-balancing switch to forward all packets destined for Port 80 (HTTP traffic) to the CacheFlow device. No client changes are required.

In lab tests, we noticed a marked improvement in performance and a significant reduction in response times once the CacheFlow 100 was activated. We ran a test tool that performed simple URL retrieval in a manner identical to a standard Web browser.

Two hundred URLs consisting of more than 3000 individual objects were retrieved by multiple clients simultaneously across a 64Kbps Kilostream link. One hundred sessions were established to perform the URL retrieval, which is equivalent to 25 full-blown Web clients.

The target Web sites were distributed across the UK, Europe and the US (see Appendix A), and some included non-cacheable data in order to provide a realistic test environment. The average retrieval times (in seconds) for entire pages and individual objects were reported for each URL. The final column in the table shows the improvement in object retrieval times, designating the non-cached figure as "1":

The most surprising figures are the second set, taken during cache initialisation. At this point, the cache was completely empty and you would thus expect to see no improvement over the "non-cached" set of figures. However, the fact that there is a clear performance gain (object retrieval times with the cache are less than half of those where no cache is used) proves that the object pipelining technique employed by the CacheFlow 100 provides significant benefits, even though none of the data was cached previously.

Of course, the page retrieval times will be influenced by the number of objects that make up the page. A single page can contain many tens or hundreds of objects – frequently the reason why some pages seem to take forever to load when you browse the Web.

"Over designed" commercial Web sites that use large numbers of objects will show the best improvement here, whilst "boring" internal Intranet sites where each page is a single object will show very little improvement. In the real world, however, virtually all Web sites will use enough objects per page to show some improvement during the cache initialisation phase.

In our opinion, this actually provides one of the strongest arguments for caching, since it demonstrates that even if every user requested different data on every access, and no two users ever requested the same data, then there would still be a performance benefit from caching.

The final two rows of figures effectively illustrate best and worst case scenarios in our fully-cached test environment. The intelligent caching engine will constantly analyse the cache contents to determine which objects are no longer required and which are due to be refreshed.

It is thus highly unlikely that you will ever see all your data served entirely from cache. The final row of figures is as close as you are likely to get to this "ideal" state of affairs, whilst the third row reflects a more "real life" scenario, where some data is being refreshed at regular intervals.

Note that some pages and objects need to be retrieved from the Web every single time, despite being fresh in the cache. This is because some pages contain cookies (which change every time they are accessed), and it is also within the Web designer’s power to designate some objects as non-cacheable - something we sincerely hope will not be practised too often. However, even if individual objects on a page are designated as non-cacheable, the remaining objects can be cached as usual.

All in all, the CacheFlow 100 proved to be of huge benefit in our test environment. Deployed in the enterprise, it will clearly do much to improve response times and decrease WAN costs significantly.

CacheFlow produces a range of devices covering everything from the smallest branch office to a large-scale ISP. If you have more than a couple of users regularly browsing the Web, it is hard to see how you can do without a device like this.

The list of URLs was indicative of UK-based enterprise usage, they were based in ten different countries, distribution as follows: