A buyer's checklist for application acceleration

Faced with big bandwidth bills every month, it’s tempting simply to buy the application accelerator 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.