Lab test: Riverbed Steelhead and Steelhead Mobile push the WAN performance envelope
Version 1.0 of the software client brings huge performance gains to CIFS file transfers, though HTTPS and NFS are not supported; Version 4.1 of the site-to-site solution shows overall performance improvement over Version 3.0, while adding key features, including HTTPS support
Reporting is very well done with statistical information and traffic reduction information available in the client software as well as aggregated in the Steelhead appliance. Each Steelhead Mobile client appears as an appliance in all reports generated by the Steelhead.
Steelhead 1520 with RiOS 4.1
For situations where a permanent end-to-end solution is required, Riverbed's Steelhead family of appliances fits the bill. Now in release 4.1, the Steelhead RiOS software just keeps getting better and better, showing increased overall performance from last release (see my review of Version 3.0) and new application optimizations for HTTPS and Oracle Java Initiator. The new release also improves HTTP acceleration and introduces MX-TCP, a method of handling packet loss on the WAN.
This round of appliance testing consisted of a pair of Steelhead 1520 appliances and the Shunra WAN simulator. To stay as consistent as possible, I used the same test set as in my previous appliance reviews and found the results to be overall better than with release 3.0. All CIFS-based file copies, whether of many small files or a single large ISO, came in with much reduced transfer times. The Steelhead was at its best when handling the large number of small files, reducing the time from just over 4 hours without optimization to an acceptable 23 minutes on a first pass.
FTP traffic showed good improvement over last year's release, with an FTP of a single large file showing a reduced transfer time from 2 hours, 40 minutes nonoptimized to just under 11 minutes on the first pass (20 minutes faster than the last release). Subsequent FTP gets of the same file clocked in nearly identically to the times recorded with release 3.0, just a tick under 1 minute.
One new feature in release 4.1 that made a big difference in packet loss is MX-TCP, a proprietary TCP optimization method for dealing with congested or "dirty" links. Normally, when TCP detects a dropped packet, it reduces the congestion window by half and slowly starts ramping back up to full speed, at least until it detects another dropped packet. This creates the classic sawtooth network performance graph. MX-TCP turns off TCP congestion control, so when packet loss occurs, instead of backing off dramatically as TCP does, MX-TCP backs off only a little.
One of my Shunra test scenarios includes 0.5 percent packet loss. I tried this in two test runs of my FTP test, one with MX-TCP off and the other with it enabled. The result was remarkable. MX-TCP proved to be a major factor in improving test results over Version 3.0. For example, a first pass without MX-TCP took longer than 51 minutes to complete, compared to just under 11 minutes with MX-TCP enabled. MX-TCP is application agnostic; a similar test using CIFS showed roughly the same improvement.