Make a Snappier Web 2.0 with App Acceleration

By Paul Rubens | Jun 1, 2007 | Print this Page
http://www.enterprisenetworkingplanet.com/netsysm/article.php/3681121/Make-a-Snappier-Web-20-with-App-Acceleration.htm
Paul Rubens

Disappointingly slow. That, unfortunately, is the verdict that many corporate users give when asked what they think of Web-based applications they access through a browser.

This is bad news when an increasing number of organizations are adopting browser-accessed versions of applications like those from SAP, Oracle, JD Edwards, or Microsoft Sharepoint, internally. It's also bad news for users of highly interactive Web 2.0 sites and the service providers who host them.

That's why the market for Web application accelerators (also known as application delivery controllers) is strong and growing rapidly. In 2005, the market for these appliances was worth around $875 million, with expected growth of 25% in 2006 to over $1 billion, according to forecasts from Gartner. "We are seeing this market growing very substantially," says Joe Skorupa, a Gartner research vice-president.

There's a variety of appliances available, including high end devices from market leader F5 Networks, based in Seattle, and FL-based Citrix Systems, as well as more simple load balancer appliances from companies like CA-based Coyote Point Systems.

At the most basic level, all these appliances carry out load balancing to relieve the load on individual servers. But the more sophisticated devices go far beyond this. For example, they can take additional load off individual Web servers by handling computing intensive tasks like SSL processing, content compression and XML processing themselves. Offloading SSL processing in particular can make a huge difference to the performance of a Web server because the overhead is so huge. To put it into perspective, the Apache Web server handles SSL traffic up to 20 times slower than unencrypted traffic, so offloading SSL processing could theoretically increase capacity by a factor of 20.

The accelerator device actually sits on the Internet side of a bank of Web servers, intercepting connections and then forwarding them on. (In fact it also works as a content cache, further reducing the load on the Web servers themselves) This interception and forwarding can make things more efficient when a client is connecting over a slow WAN link (or even a congested LAN). A busy server may reach its concurrency limit – the number of concurrent connections (and therefore users) it is capable of handling. Since the accelerator waits till it has received the full request over the slow link before establishing a fast connection directly to the Web server, sending the request on, receiving a response, and closing the connection again, the server is tied up for far less time. While the accelerator is occupied sending the response back to the end user over the slower link, the Web server is free to start handling another request.

Web 2.0 sites which rely on Ajax applications (or similar) can suffer particularly poor performance because they require longer than normal keepalive times to remain responsive, although many web servers reduce the keepalive to 5 seconds or less to increase the number of users that can be handled in a given period. In this case, Ajax applications can cause an inordinate amount of connection establishment and reestablishment, which can degrade performance considerably.

Accelerators can ameliorate this problem by "re-using" connections to the Web server: holding a connection open and sending more requests to it from other users. This reduces the amount of time the server is occupied in setting up connections and closing down connections. Effectively, it thinks it is dealing with a small number of connections over a fast LAN link, when the reality may be that it is dealing with a far greater number of connections, over slow links.

The $64,000 question then is how good are these appliances? Do they really make a difference? Absolutely, says Skorupa. "When properly deployed these devices can reduce the number of web servers you need by 20%-50%. That means less hardware, less rack space, less air conditioning and less power. More importantly, if you are paying $20k to $30k for each server license, that can mean big cost savings. Typically one of these application delivery controllers costs between $20k and $70k and has a payback period of less than 12 months."

As a bonus, an application delivery controller can also beef up the security of the Web servers behind it in a number of ways. For a start, it allows the use of https far more cost effectively (as less servers are required). It also presents a single IP address to the world, while your Web servers shelter behind it. Like a NAT router, this makes it very hard indeed for anyone to know what Web servers are actually present, and what software they are running, so it makes it harder to attack them. And the devices can also carry out content modification to filter out data from the packets heading out onto the Internet – data such as social security numbers or credit card numbers which have not had all but the last four digits starred out.

Are there any circumstances when it's not appropriate to use one of these devices? Certainly, if you only have a few dozen users accessing a single server or if you are running IPSec end to end, Skorupa says. Anyone else, from an enterprise running Web based applications to a service provider hosting Web 2.0 sites, probably should be using one. And with a payback period of months rather than years, who would argue against it?