That's Not Always an Option

Improving the performance of AJAX applications by switching servers isn't always feasible in a real environment

It's nice to see the analysis of AJAX I did last year being validated, especially by one of the creators of the popular AJAX-focused toolkit, Dojo.

While I agree with Dylan's assessment of where to begin the "search & destroy mission" and the reasons behind poor performance of AJAX-based applications, I just can't get behind his suggestion to switch Web servers simply to resolve highly aggressive polling-based applications.

The best place to begin a thorough search & destroy mission is with HTTP-level performance problems that can be resolved in server configuration and fine-tuning. Is the caching configured properly? Are there issues with load balancing? How many concurrent requests per server before performance suffers? AJAX applications typically reduce the data size per request, but highly aggressive polling can saturate your servers with too many requests.

As AJAX applications become increasingly common, users expect real-time updates to accompany their real-time experience. To be effective, real-time or highly collaborative applications require a significant amount of AJAX polling to make the application work. If this is simply too demanding on your Web server, you may want to consider switching to a Comet server implementation such as Cometd, Lightstreamer, KnowNow, or lighttpd. Comet servers are optimized for longer-lived connections and higher volumes of concurrency than typical Web servers.

There are several reasons why this option simply isn't feasible. First and most obvious would be the availability of such servers if you're hosting an application. The hosting provider is going to determine what servers are available, and even they are going to consider stability and potential costs of maintenance (in terms of skills, training, and hardware required) before simply deploying yet another web server.

Within the enterprise, the changes of deploying another web server are even slimmer and will certainly take more time. Similar factors must be considered, as well as the stability and reliability of the software and the cost-benefit analysis of whether another server is really worth the investment.

It often simply isn't as simple as switching to a new web server.

In large scale environments it's almost certainly more advantageous to implement a known, proven method to address the issues associated with highly aggressive polling applications such as AJAX. Application delivery network infrastructure handles these issues with more than just old fashioned load balancing. TCP multiplexing has long been an advanced feature set of application delivery controllers like BIG-IP and helps to alleviate the burden on servers caused by excessive connections often by up to 33%. Additionally, advanced features and product modules that support caching - even of so-called dynamic content - like WebAccelerator can further keep web servers from becoming undully challenged by this new breed of applications.

Employing an application delivery network solution has additional benefits over tuning the cache on a web server or switching to a new web server, such as compression. WebAccelerator specifically goes one step further and through its unique MultiConnect technology improves the handling of connections for AJAX applications on the browser as well, where connections are typically limited by defaut configurations. Increasing the connections available on the client further improves the performance of AJAX applications by allowing requests to be delivered as soon as possible, rather than whenever a connection becomes available.  

Certainly changing your web server of choice is an option, but there are too many situations and environments where such a choice is not feasible. In such situations it might be wiser to consider a transparently deployed option such as an application delivery controller that can provide benefits above and beyond even the most highly tuned web server.

Imbibing: Water

Published Jul 24, 2007
Version 1.0
No CommentsBe the first to comment