While caching and CDNs (content-delivery networks) can solve some Internet-performance problems by moving content closer to users, neither is a panacea. Some clients simply have small pipes and cannot transfer in a timely manner the copious amounts of data on many Web sites.
Hurry Up and Wait
The last-mile problem is twofold. First, a modem adds 100 milliseconds of latency to each transmission. Period. It doesn't matter whether the modem transmits at 14.4 Kbps or 56 Kbps. And because no fewer than three exchanges are required for a TCP handshake, the latency when setting up a connection to request a single Web page object -- an image, a Flash object or an audio file -- is already 300 milliseconds, not counting the transfer. That's the second piece of the problem -- slow transfer speeds.
In the workplace, with a fat connection, transfer speeds are not an issue. Travelers and telecommuters, however, are at the mercy of hotels and airports, which all too often have only dial-up links. But users don't care about the technical reasons for slow connections. All they want is to retrieve e-mail or browse the Web, and they want to do it this century.
So what's the solution? Caching, certainly, is one answer. Moving the content to the edge so the client has faster access is a good idea, but it's no silver bullet. The total transmission time from ISP to the cache as opposed to the origin server is negligible when compared with the transmission time from the ISP to the client. Caches do take some of the burden of slow connections off the origin server, improving the server's performance, but caching doesn't address the last mile.
But take heart: Products are available that address such last-mile difficulties as restrictive bandwidth limitations from users to their ISPs. We tested content accelerators from BoostWorks, FineGround Networks, Fourelle Systems, Packeteer and Redline Networks in our Green Bay, Wis., Real-World Labs®. Our only requirement was that the solutions not be based solely on caching technology. Although many of the products we tested use caching, it is ancillary to their primary function: boosting the speed of data transfers in restricted-bandwidth environments.
We Don't Care HOW You Do It ...
Content-acceleration products speed up last-mile transmissions in a number of ways. Generally, these technologies attempt to reduce the size of the data being returned to the client, sending fewer packets while still providing a rich browsing experience. Text compression is typical and is the "content-encoding" portion of the HTTP 1.1 standard. Industry-standard text-compression techniques use gzip or the Unix compression format to put large quantities of text into a more compact format, enabling faster downloads. This technique works great -- if your browser is HTTP 1.1ýcompliant.
However, HTTP 1.1 compression condenses only text -- HTML, WML (Wireless Markup Language) or XML (Extensible Markup Language), for example. It does nothing about the bandwidth-hogging images that populate the bulk of many Web sites. Some solutions squeeze images using optimization. JPEG compression is common and is based on the eye's ability to detect detail in complex scenes. Essentially, JPEG-compression techniques compromise detail where viewers will least notice the loss (detail is irretrievably lost during compression, so JPEG is called a "lossy" compression). Compression of JPEG images can save download time, and most users won't miss the bits a bit.
Another form of compression involves stripping out unnecessary parts of the text -- generally, comments in scripting languages and white space. Most products refer to this process as "optimization." While developers need those comments and white space, the browser does not. For example, a browser will interpret both versions of the HTML text below without a problem. But the top example contains at least 12 extra bytes -- spaces and carriage return/line feeds -- compared with the bottom example.
HTML with white space:
<html>
<body>
</body>
</html>
HTML without white space:
<html><body></body></html>
Multiply this number by the size of a page, and you can see why this technique is called optimization. Stripping this information is harmless and can improve transfer times dramatically.
Another technology, delta updating, is different from the other methods. It involves manipulation of the URL on the server side and returning only those bits and bytes that have changed within a page. Delta updating relies on the comparison of a base page with the content on the origin server and the ability of the browser to execute a partial replace of the page. It works well on static pages with few content changes but is not nearly as effective with dynamically generated content. Delta updating also is more fragile than other technologies: It uses a combination of DHTML (Dynamic HTML) and JavaScript to replace the changed bytes in a page and therefore is heavily dependent on the client's browser.
Regardless of the technology used to improve performance, the content must be served, even if the browser does not support the acceleration technique used. The content-acceleration device or software must provide a pass-through model, where content is passed unmodified to those browsers that do not support certain techniques. All the products we tested offer this and are cautious to the point of sacrificing the advantage of acceleration rather than risk returning faulty -- or no -- content to the browser.
Most of the products we tested offer support for both content encoding support and image compression. While Fourelle Systems' Venturi is the only product to require a desktop client, it is also the only one to provide support for any TCP-based protocol; the other products support only HTTP. Redline Networks offers enhanced server performance through its real-time acceleration feature, which no other product we tested provides, though Packeteer's AppCelera includes a TCP multiplexing feature to alleviate some of the problems that occur as a result of slow modems and slow servers.
We examined deployment models, the actual performance of each product, and the configuration and management of each solution. We also looked at the reliability of each product, considering the ability to pass through requests as well as the general robustness of the solution. A big concern was the fault-tolerance of each product: Because most solutions operate in-line as a transparent proxy or as a direct proxy, they easily could become a single point of failure -- a big no-no in a robust, fault-tolerant infrastructure.
We took a look at price, graded each product on its configuration and management methods, and weighed the reliance each product has on the client, from little or no reliance to requiring JavaScript support to the need for a client-side agent.
Just Do It
We set up a Web site with a static "brochureware" page and a page with dynamic content (see "How We Tested Content Accelerators") and deployed each product to front the Web server, aiming to increase performance on our simulated 14.4-Kbps connection. Packeteer's AppCelera ICX-75s was a standout and earned our Editor's Choice award. The ICX-75s offers an ease of deployment matched only by that of Redline Networks' TX 2100, the runner-up in our speed-demon game. With its intuitive Web-based management, the ICX-75s offers an easy-to-use remote-control system that left FineGround's manual-editing method in the dust and highlighted the weakness of BoostWorks' complicated configuration method, which is too much to ask of an overburdened staff.
Packeteer's solution also provided a good increase in performance via compression while ensuring that the device did not become a single point of failure. We can't say the same about the products from BoostWorks and Fourelle Systems. Add to this the ICX-75s' support of SSL acceleration, and you have a well-rounded product sure to enhance your customers' browsing experience.
Runner-up BoostWorks' BoostWeb provided great performance gains but required extensive setup, and the company's use of odd terminology made this task more difficult than necessary. BoostWeb offers imaging compression and, therefore, better transfer times, enabling it to beat out the TX 2100, but this wasn't enough to push it to the top. Still, its reasonable price and minimal reliance on the browser gave BoostWeb the points to put it in second place.
Redline's entry showed us some phenomenal server-side improvements in capacity and provided a decent boost to clients. The TX 2100's support for myriad browsers inflated its score, especially since competitor FineGround Condenser 3.0 requires specific browser versions to work correctly. The TX was held back from a higher spot because its philosophy regarding images (never touch them) allowed less of a performance gain than Packeteer's and BoostWorks' products did.
FineGround has the most innovative, yet fragile technology for dealing with content acceleration. The Condenser uses delta technology and a sensitive cache to decrease the amount of data returned to the browser. The data that is returned is used to do byte replacement via JavaScript. So if the page has changed 2 bytes, you won't get much more than that back from the request, which is nice. But if you don't use JavaScript, you won't get any benefit. Performance improvements were skewed when testing the Condenser, since the first hit on a page will show only the improvements gained by text compression. Subsequent hits showed a huge gain in performance because caching and delta technology provided for minimal transfers over the line.
Fourelle Systems' Venturi exhibited incredible performance increases thanks to its proprietary transfer protocol coupled with its image and text-compression technology. Unfortunately, the Venturi's pricing and requirement for a client-side application held it back from a better showing.
REPORTS
ANALYTICS
Follow 
