Faced with big bandwidth bills every month, it's tempting simply to buy the application with the best performance. Tempting, but not necessarily correct.
Performance matters, but it's far from the only consideration. Numerous other issues should factor into any buying decision, including functionality, network design, security and application support. What follows are six key questions buyers should take into account while considering which application-acceleration system will best suit their own environment.
1. What are my goals for application acceleration? All accelerators reduce the number of bits on the wire, but they do so with different goals.
Most devices focus on WAN bandwidth reduction. That's a worthy goal when links are overloaded and the cost of adding more WAN capacity is an issue. But reducing bandwidth isn't the only thing application-acceleration devices do.
In other situations, enterprises may need to speed bulk data transfers or improve response times for interactive applications. Examples of the former include backups and disaster-recovery processes, both of which require moving a lot of data in a hurry. (Silver Peak, in particular, focuses on speeding high-bandwidth applications.) Examples of the latter include databases and other transaction-processing applications where there's revenue tied to every transaction.
And organizations may have yet other needs for application acceleration beyond bandwidth reduction or faster transfer times. For example, a company that routinely distributes large videos or databases might want to locate data closer to customers using "prepopulation" or "prepositioning" capabilities, intelligent forms of caching that places frequently requested data on remote-site appliances.
Our advice: Make sure vendors understand your main goal for application acceleration -- bandwidth reduction, faster bulk transfers or response-time improvement -- and let them pinpoint which of their systems come closest to achieving that goal.
2. What's the difference between caching and application acceleration? Caching -- getting data close to the user -- is the oldest trick in performance tuning, and it's still a great idea. Application-acceleration devices use caching, but do so in fundamentally different ways than conventional Web caches and their optimization toolkits extend well beyond caching.
Conventional caches work at the file level. That's fine for static content, but it's no help when something changes. Consider a manufacturing company that routinely distributes a 10GB parts database to multiple sites. If just one record changes, caches would need to retrieve the whole database again.
Application-acceleration devices work smarter: They retrieve only the changes. As user data flows through a pair of devices, each one catalogs the blocks of data it sees and makes an index of those blocks. Note that a "block" is not the same as a file; it's just a fixed amount of data.
The next time users request data, the devices compare their indexes. If nothing changed, the device closest to the user serves up the data. If something's new, the remote device retrieves the changed data, and both devices put new blocks and new indexes into their data stores. Over time, application-acceleration devices build up "dictionaries" that are hundreds of gigabytes or terabytes in size.
Dictionaries have three advantages over conventional caching. First, they require transmission only of changes to an object, not the entire object. Second, they still save bandwidth if an object is changed and then later changed back, because the original data still exists in the dictionaries. Finally, dictionaries are application-agnostic. In contrast, caches typically work only with a single application. All the devices we tested use dictionaries. Blue Coat's devices are also Web caches, while the Cisco devices are CIFS caches.
Acceleration devices perform many other optimizations as well. All compress blocks of data flowing between pairs of devices, with big bandwidth savings shown in our tests. But compression won't help with near-random data patterns, such as video or encrypted data (an exception is when clients repeatedly request the same near-random data).
These devices also tweak TCP and CIFS parameters to speed data transfer. At the TCP level, these devices make use of many high-performance options missing from Microsoft's stack. Some devices do inverse multiplexing of client-side connections, reducing connection setup overhead. The devices we tested also optimize CIFS, Microsoft's infamously chatty file-transfer protocol. For sites looking to optimize Windows traffic, CIFS-optimization efficiency is a top concern.
Our advice: Make certain vendors are not pushing the notion that application-acceleration devices are "just" file caches; they're smarter about storing data and employ other optimizations to boot.
3. How do application-acceleration devices operate with the rest of my network? Imagine the effect on the network if an intermediate device were to terminate TCP connections, alter IP addresses and port numbers, and possibly scramble packet payloads. That's one way of describing exactly what many acceleration devices do. While these effects aren't always harmful and may be desirable, network transparency may be a concern.
Altering or hiding packet contents can cripple devices that need to see those contents, such as firewalls, bandwidth managers, and QoS-enabled routers. All the devices we tested optionally can be configured to run in a transparent mode, but might lose optimization efficiency in doing so. Of course, if other devices don't examine traffic contents, this isn't an issue.
Another design concern is whether devices operate inline or in so-called off-path mode. Cisco and Riverbed devices can be configured for off-path operation, meaning traffic passes up through a separate software module, while the device simply bridges nonoptimized traffic.
All devices tested fall back to passthrough mode if acceleration is disabled, a useful feature in maintaining availability, and all offer failover capabilities. To further enhance availability, the Blue Coat and Cisco devices also support clustering of multiple application-acceleration devices.
Our advice: Grill vendors on whether or not their product will "blind" other devices, such as firewalls or bandwidth managers, that need to see packet contents.
4. What are the security implications for application acceleration? On the plus side, acceleration devices can improve data privacy by setting up encrypted tunnels between sites. Because these tunnels carry all data (or some user-defined portion of data that's sensitive), there's no need to set up authentication and encryption on a per-application basis.
But these devices also keep copies of all user data, creating disclosure concerns and possible compliance issues for industries that require end-to-end encryption. Network managers will need to revise security policies to cover data stored on acceleration devices, not only while it's in use but when it's retired (to ensure its disks are wiped clean before disposal or recycling). The Cisco and Silver Peak devices have an elegant solution: They encrypt data on disk, rendering it useless to an attacker.
Our advice: Push potential vendors to explain how you could revise security policies as appropriate to deal with use and disposal of sensitive data stored on their application-acceleration devices.
5. What's my application mix? Acceleration-device vendors differ in terms of the number and type of applications they can optimize.
Not all application-acceleration devices optimize UDP-based traffic, including the Blue Coat appliances in our tests. Given that voice, video, file sharing and some backup traffic may use UDP, support for UDP-based applications will likely become more important over time.
For many enterprises, the mission-critical, revenue-bearing application is something developed in-house. Even the longest list of supported standard applications won't help here, but even so the application may still be a good candidate for TCP or other optimizations. Testing support for custom applications is critical in such situations.
Our advice: Force any potential vendor to address how its product will directly address the prospect of speeding up your organization's application mix.
6. Where are my users? Most acceleration today is done between sites, with a symmetrical pair of devices at either end of a WAN link. However, some client software is beginning to become available for road warriors and telecommuters.
Blue Coat recently released client software that performs most, but not all, the same functions of its hardware appliances. The client code does caching, compression, L4/L7 optimization, but it doesn't perform WAN-data reduction. Riverbed also has announced an acceleration client, and other vendors are likely to follow.
Our advice: If you need to speed traffic going out to a mobile workforce, press vendors about their plans to provide application-acceleration clients as well as site-to-site appliances.
David Newman is president of Network Test, an independent test lab in Westlake Village, California. He can be reached at dnewman@networktest.com.