NetCache architecture and deployment

Abstract

This paper describes the architecture of Network Appliance's NetCache proxy cache. It discusses sizing proxy caches, contrasts the advantages and disadvantages of transparent caching, and reviews mechanisms to provide highly available caches. It also reports cache hit rates and summarizes our experience deploying proxy caching at Internet Service Providers (ISP) and corporate firewalls and intranets.

Introduction

When properly deployed, proxy caching reduces network bandwidth consumption and improves perceived network quality of service. However, when improperly deployed or inadequately sized, proxy caches degrade performance, need constant maintenance, and irritate users.

This paper summarizes four years of experience building and deploying proxy caches. NetCache springs from the Harvest cache project, which I led (the Harvest project still continues in the public domain under the moniker `Squid') [1]. What attracted us to Web caches was our research that predicted that a hierarchical FTP cache would reduce Internet backbone traffic by 35% [2]. We proposed a hierarchical Web caching protocol that became known as the Inter-Cache-Protocol [3]. ICP lets cooperating caches robustly detect failure and recover from it quickly. As a team, we resolved to make the Web scale more efficiently than the Domain Name System, which consumes 20 times more bandwidth than it really needs [4]. We developed the Harvest cache in the public domain, and cooperative Web caching swept through Europe, Asia, Latin America, and the Pacific.

To fill the need for a scalable, commercially supported, highly available Web cache, we developed NetCache. The NetCache software versions run on UNIX and NT; the NetCache Appliance runs on Network Appliance's own Data ONTAP microkernel [5]. All versions of NetCache are built from a common source tree so their features are nearly identical. The high-end NetCache Appliance is roughly four times faster than the NetCache software running on a 2-processor, 300 MHz, Ultra-SPARC. The NetCache Appliance sits on top of Network Appliance's WAFL file system [6]. The appliance achieves superior performance because: (1) WAFL achieves 2–3 times more disk operations per second than traditional file systems, (2) because the ONTAP microkernel eliminates most of the data copying between the file system and network stack, and (3) because the appliance's event handling efficiently demultiplexes network connections. The NetCache Appliance survives disk failure transparently (without losing its configuration files, its log files, or even its cached contents) because it is RAID-based.

We now have two years experience supporting NetCache for mission critical customers. As of December 1997, our biggest ISP customer had 500,000 dial-up customers and more than a hundred dial-in POPs. Our biggest enterprise customer had 100,000 desktop computer systems with browsers. Fig. 1 shows cache sizes and hit rates of an assortment of NetCache ISP and enterprise customers. Cache sizes range from 6 to 28 GB and WAN bandwidths range from multiple T1 to T3. Bandwidth savings at these sites average 35%.

During the past two years, hit rates have remained stable, despite the proliferation of dynamic Web content. The explanation for this is simple. Fig. 2 shows that 70% of Web traffic consists of graphic URLs and software downloads. Even if all `html' URLs were dynamic and non-cacheable, 80–90% of the Web's bytes would remain cacheable. In the coming year, as HTTP-1.1 gets deployed, we anticipate higher hit rates as Web servers begin exploiting cache-control headers.

After reviewing NetCache's architecture, we discuss how to scale NetCache to arbitrary WAN bandwidths and derive rules-of-thumb for sizing single nodes. Finally, we discuss the advantages and drawbacks of transparent caching.