One of the hot infrastructure elements of ISP networks is the cache server. Cache servers are supposed to reduce network traffic, improve application performance, and make users happy and vendors profitable. Now cache vendors want to extend these benefits to enterprise networks, specifically intranets. But before you make the cache commitment, take a closer look at the issues involved.
Caching is something everybody with a Web browser has done. When you load a URL from the Internet, your browser places a copy of the content in a directory. If you come back to that URL later, you'll load a disk copy instead of pulling a new one over the Internet. This makes complex pages load faster and reduces traffic on the Internet.
However, caching is limited. With browser caches, the cache stores one user's pages and is accessible only to that user. If the user at the next desk loads a page you've loaded a second before, he has to get another copy of it.
To make caching more efficient, you put a kind of "collective cache," or cache server, at a place where many users would pass through to access Web content. The cache server stores pages accessed by any of the users whose requests and responses pass through them.
Caching can produce dramatic savings for an ISP. So it would seem that enterprise caching is a no-brainer. However, the situation in an enterprise intranet isn't the same as in an ISP. Here are some points to consider before adding caching to your network.
First, caching is useful only if there is a place you can put a cache server so that many URL requests and server responses will pass through it. If your network doesn't focus a lot of client/server traffic across a few pipes, you'll need a lot of cache servers to cover all the information paths. This division of traffic will increase the risk that Client A will ask for a page that has been retrieved by Client B but is cached in a server that isn't on Client A's path and therefore can't be used.
A second issue is repetitive use of common content. If two workers access a common repository of pages and often retrieve the same data in succession, caching could cut out almost half the traffic. But if one worker is browsing the personnel manual and the other the company's product catalog, there won't be any common content and caching won't reduce the number of times the servers are accessed and the network is used to trans-port the content.
With the Internet, in most cases, the content associated with a given URL changes only infrequently, and there are many URLs (including those for major companies such as Microsoft, IBM and Cisco) that are accessed regularly by many users. With enterprise intranets, there are fewer boilerplate pages, and often, less-glitzy graphics. Hence, there is less cache benefit.
In fact, the key application of most successful intranets normally can't be cached at all. Many intranet users are using the Common Gateway Interface (CGI) or Java to do database queries and deliver the results to client browsers as HTML. These kinds of content pages are constructed anew with each query, and there's no way to cache the content to reduce access. Even if there were, there would be a risk that the database was updated between requests; the second user would then see an out-of-date record.
Another issue of caching is security and journaling of use. If the content server is applying any form of security screening to requests for pages, or if it is counting the number of accesses for billing, a cache will defeat the process by intercepting the request and filling it without security checks or counting.
The final issue with caching is cost. Let's suppose you have an intranet application that combines host data obtained from a query with help files and other material. While the query data couldn't be cached, how about the rest? The answer may be that it would be better to store such content locally rather than to cache it.
If you build an intranet application and design the pages and hyperlinks, you can allow each branch office, workgroup or even worker to store common boilerplate content on an existing server or client hard drive. No new cache server would be needed and no additional cost incurred.
There are applications where a cache may be helpful. If a database of product information is updated relatively infrequently but is too large to distribute and control, it may help to provide caching if this database is accessed frequently and the number of workers who access it per location is high. But for most users, the enterprise cache is a solution in search of a problem.
Nolle is president of CIMI Corp., a technology assessment firm in Voorhees, N.J. He can be reached at (609) 753-0004 or email@example.com.