Riverbed's Steelhead swims through WAN bottlenecks
WAN accelerator eliminates the wait for inter-office file transfers
Steelhead, on the other hand, does not care what the file is named, how or when it was updated, or how it was transferred across the WAN. Because the appliance does not cache “files” as such, but chunks of data it has plucked from traffic streams, it will always locate some segments of an already-requested file in its cache — eliminating round trips for entire files that have been only slightly changed or renamed. In fact, Steelhead ignores what application created the chunk. If a requested Word document contains a piece of data originally found in an Excel sheet, Steelhead will still use the data, thereby decreasing access time.
I tested this feature extensively in my lab to see just how effective Riverbed’s acceleration would be. For my WAN circuit, I used a Pentium III PC running FreeBSD and equipped with two 10/100Mbps network adapters. FreeBSD has a built-in service called DummyNet (part of IPchains) that allows you to set link speed, packet loss, and latency between two network interfaces. I used DummyNet as my WAN circuit engine.
More Files, Less Filling
Using various file types and transmission methods (file copy, FTP, HTTP, and Microsoft Outlook), I saw huge time savings when using Steelhead in-line with my WAN circuit. For example, in one test I simulated a T1 satellite WAN link by defining the circuit as 1.536Mbps with 3 percent packet loss and 800ms average latency (400ms in each direction). Over the raw link, it took more than 25 minutes to FTP an 8MB PDF document. With Steelhead in place and “hot” (meaning the data had passed through the cache at least twice before), it took only 12 seconds to FTP the same file.
To make sure Steelhead was smarter than a standard file cache, I renamed the file and transferred it again. Again the file was retrieved in roughly 12 seconds. Next, instead of using FTP to send the file, I simply copied it using Windows Explorer and saw the same results. In all of my tests, no matter how I tried to fool it, either through renaming the file or changing the transport, Steelhead always correctly identified the traffic and optimized it for a huge time savings.
Steelhead also improves WAN performance by reducing the amount of network chatter (the overhead data transmitted between systems simply to facilitate communications) caused by MAPI (Messaging API) and CIFS clients. Microsoft Exchange is very chatty, and the process of copying a file creates an enormous amount of network overhead. Steelhead understands these two protocols and intercepts the chat requests. Instead of sending all of the chats across the WAN, smaller references are sent over the WAN that tell the other Steelhead how to recreate the entire conversation. To the application, all of the conversations take place, preserving any user permissions or other dependencies. This substantially reduces WAN traffic but still maintains the end-to-end conversation. Riverbed said it will release support for other protocols over time.
To say I was impressed with the Steelhead would be an understatement. I have tested other file caching systems, and none have come close to delivering the overall time reduction provided by this product. Furthermore, Steelhead is self-tuning and virtually maintenance free. A true appliance, this box is as close to a hands-off device as you will find.