Friday, April 21st, 2006

Ajax and Scaleability

Category: Editorial, Server

Billy Newport recently kicked off a conversation about Ajax and its impact on servers.

I think it’s becoming clear now that AJAX enabled applications generate a higher load on an application server than a non AJAX application. I guess customers will have to size their boxes appropriately as a result. The problem is related to the fact that an AJAX enabled pages simply send more requests to the server because of their high level of interaction versus a conventional web page.

The ensuing discussion led to a further post on the impact of lazy fetching (aka Predictive Fetch).

Some AJAX sites fetch all the data and then display it in an interactive fashion. Others will fetch a reduced set of data and then pull the missing data when it’s requested. It’s the latter where care needs to be taken. Lazy data fetches are great from a user point of view. They are fast, they make the app responsive. But, if a lot of data is fetched lazily then this is a high overhead way of fetching the data. It may work well under low load but as load increases, the servers may slow down unacceptably due to the extra overhead of high frequency/low content RPCs.

James Governor questions the claim, along with some commenters in Billy’s blog – Billy has some good comments and the discussion is worth following. Nate Schutta has addressed performance in the past, says “it depends”, and points to some real-world evidence of scaleability:

Considering that Basecamp ran on one server for its first year, I’m curious what causes him to make a statement like that. I’m not saying there isn’t some truth to it, but I haven’t been hearing any screaming about this issue; I’m not sure, but I suspect Gmail gets a few hits a day and it seems to be doing OK…

Tim Bray isn’t loving the whole question.

The question is dangerous because it’s meaningless and unanswerable. Your typical Web page will, in the process of loading, call back to the server for a bunch of stylesheets and graphics and scripts and so on: for example, this ongoing page calls out to three different graphics, one stylesheet, and one JavaScript file. It also has one “AJAXy” XMLHttpRequest call … I’ve argued elsewhere that AJAX can be a performance win, system-wide; but that argument too is contingent on context, lots of context.

An Ajax app doesn’t have to be like Google Suggest and respond to (almost) each keystroke. But there are times when a high level of interactivity is the ideal thing for users, and at least for those situations, it’s important to look at strategies for scaleability and optimal performance.

Posted by Michael Mahemoff at 5:31 am

4 rating from 25 votes


Comments feed TrackBack URI

That is actually something I have experienced too. During the whole “AJAX-boom” no one seemed to have cared about this, and implemented some of the most retarded ways of using ajax. I am sure alot of people are actually seeing similar problems with their servers.

Hopefully this will slow down people’s use of AJAX to only the most worth-while applications instead of using it on every button click and page load.

Comment by Philip Plante — April 21, 2006

Here are guidelines that I have when working with Ajax-enabled “weblications”. First I have to declare that I exclusively use XML when exchanging data with the server and primarily with POST-mathod.

– If there are data that will be presented to the user but I am sure that this data will not be changed, than I create an static XML-file with necessary data and recover it with a GET method.

– Some calls do not need to be executed immidiately, so instead of an immidiate POST to the server, I queue up such calls and make sure that if the queue contains anything “onunload”, I submit it with a syncronous call. An example of such call; if a node in a tree is renamed. In the GUI, the node is renamed with DOM-methods and the request is queued up.

– Instead of a request on each keystroke, use space and return key as request invokers. Perhaps not equally “sexy” as on each keystroke, but it’s more server-friendly, yet afficient.

Are there other smart guidelines you have? I am really interrested…

Comment by Hakan Bilgin — April 21, 2006

Using XHR etc. opens up the idea of potentially eliminating the old-school “page 1 2 3 4 …” method of browsing content, but comes with a number of possible gotchas – namely performance – and on the client too, not just the server.
I think the new Yahoo! Mail does a good job of loading data “on-demand” and subsequently caching it, avoiding redundant requests (ie. scrolling through a large folder of messages.)
(General disclaimer: I work at Y!.)

Comment by Scott Schiller — April 21, 2006

What people may not realize is that AJAX makes web apps multi-threaded. That is a more fundamental shift in programming model than a mere server load histogram pattern change.

Race conditions will be the bane of AJAX apps, especially those that go too far on a limb.

Comment by Weiqi Gao — April 21, 2006

Beyond becoming multi-threaded, AJAX is beginning to open up the web to new types of applications, ones that are document centric (word processors, modeling tools, etc.) rather than data and transaction centric, i.e. all those rectangular CRUD applications that make up 99.9% of webapps. It also means that the sorts and types of rich client interactions are going to dwarf the traffic that we see today.

That means 1. abandoning the forms-and-reports way of writing webapps (which will break when you try to write something like rational rose as a webapp) and moving to the component GUI model (like Swing, Winforms, etc.) and 2. being very clever about the frequency and size of your XHR conversations with the server. From my unscientific tests (Yahoo mail and Google calendar) it seems that some are winning and some are losing the battle on fat XHR. I don’t think any amount of JSON or compressed XML magic will solve the problem of poor design.

I think the right way to achieve all of this is by moving AJAX/Webapp development to component GUI application frameworks. Properly done, they have the potential to hide all of the messy bits like exposing too much of your business logic on the client side, optimizing XHR requests for components that have empty server-side event listeners, reducing the impedence mismatch between the Javascript/CSS/XHTML world and the business logic.

Those who don’t move in this direction will be stuck building and maintaining ever more complex applications because they didn’t make the shift to a new design. It’s time to think of the browser simply as a display server.

Comment by dkappe — April 21, 2006

The idea of a display server is core to TIBCO’s AJAX approach with TIBCO General Interface. In fact if you look closely at the architecture TIBCO General Interface is modeled after an application server — that runs in the browser. Of course it’s max capacity is one user — but that’s the whole point — distributing presentation processing to the client and off the server. This is synergistic with the trend towards service oriented architectures in enteprise solutions as well as software products and many services (SOA, XML, JSON, etc…) on the Web in general. By NOT generating HTML on the server and distributing that task it to the client you usurp the CPU processor power of the client machine that previously went unused and take that load off the server. Thus the question in this architectural approach to AJAX solutions is how do you scale those XML, SOAP, JSON services — not how to you scale AJAX. In addition with TIBCO GI’s client-side data cache, redunant requests for information are avoided and the server is contacted less frequently further reducing load. See a realted case study here at

Comment by Kevin Hakman — April 22, 2006

More Ajax and Scalability

Well, more than a few people have picked up on the various articles floating around regarding Ajax and scalability. Thanks to Michael Mahemoff for reading my piece and reposting it (check the comments). Stuart Halloway over on Relevance also picked u…

Trackback by — April 24, 2006

Leave a comment

You must be logged in to post a comment.