« Heads up: There are many flavors of query | Main | The hidden costs of lazy fetch with AJAX »

April 18, 2006

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.

A higher application server load will also translate in to higher database load unless steps are taken to help with this. Distributed caching is a critical piece of the toolkit to help with this. Technologies like ObjectGrid allow an application server to pull data from a remote ObjectGrid cluster in under a ms. It can be used for HTTP session persistence or used directly in the application for more control over how it works, how you lock data etc.

April 18, 2006 | Permalink


When you say "I think it's becoming clear now that AJAX enabled applications generate a higher load on an application server than a non AJAX application" do you have any references or data to back it up? Even though there are more requests back and forth over the wire, you also reduce the amount of redundant data sent over the wire, because you only have to fetch data that you need to satisfy a user gesture.

E.g. if you look at a portal site, every request requires that you retransmit all of the portals, even the ones that haven't changed as a result of your request.

Another thing to consider is that in a pure Ajax application (i.e. one that's not a hybrid of a server-side technology like JSF that emits Ajax-widgets), the server can pretty much just respond to requests from the Ajax client in a stateless manner, and all of the state gets distributed to the client, greatly reducing the memory resources on the server. I'm working on an app like this for IBM Rational and we're really excited about the *decreased* load on the server by distributing state to clients.

I would look for some data and studies before concluding that Ajax web clients put greater load on the server.

Posted by: Bill Higgins | Apr 18, 2006 11:56:53 AM

More traffic? This sounds bogus to me. I never understood this comment. What would create this kind of traffic? Is somebody polling a huge amount of useless data from the server asynchronously or what?

The AJAX model gives greater flexibility on the "use" of the server and hence the amount of traffic passed back and forth. The kind of flexibility that was not available before where any change required page updates, even if they weren't UI related! (Change of a validation rule or whatnot).

So, I too would request some type of hard data and also the client-server communications that was used in the comparison.

Posted by: Boris Kuschel | Apr 18, 2006 12:33:07 PM

The data on the AJAX client came from somewhere. A common pattern seems to be lazy fetching when the client needs the data. This generates an RPC and the payload is indeed smaller. But, the server still took the hit to pull the smaller piece of data so the server overhead per byte of data is higher.

Also, fetching large blocks of data with one transaction from a database is more efficient than fetching small pieces using seperate transactions from the same database. So, the database load isn't likely to be lower because of lazy loading, in fact, it's the opposite. It's this point which I'm addressing in this blog entry. Using the OG to catch a chunk and then allow the lazy data fetches to work against pieces of the chunk versus slamming the DB with a lot of small requests which will load up the DB. If the AJAX model is lazy fetch then cool but recognize that the work done/request is going to be lower which means more app server overhead for a given number of requests and the database load follows the same pattern. Using distributed caching won't help with the app server load but may help with the db/back end load.

Posted by: Billy | Apr 18, 2006 1:05:10 PM

My completely wild-assed guess? :-)

More traffic, but simpler traffic. Server doesn't need to generate loads of redundant stuff (per Bill's comment of portlet changes requiring complete page refreshes).

Agree w/Billy, certainly, that caching is very important. Most of the requests probably being reads + queries, for many apps. Peer-to-peer caching may even be appropriate in some cases (ala bittorrent).

Interesting point from Billy where he mentions session data. AJAX can be used to remove the need for session data stored on the server AT ALL. Building fat clients again, this time, in a web browser. This helps the server ... no need to store session data at all!

It's also relevant to note that AJAX is not just useful from a web browser, but from a stand-alone app using whatever appropriate HTTP client API is available (for instance, the various Flickr update utilities).

Posted by: Patrick Mueller | Apr 18, 2006 2:58:05 PM

When compared to the alternative of reloading a whole page which may contain other elements which are database driven, having AJAX just update the part you need updating will result in less server load.

Posted by: Critters | Apr 19, 2006 7:28:07 AM

It depends, if the page only fetched a small amount of the total data then the extra cost of lazy fetches would do as you say. But, if most of the data was fetched then the fluery (excuse the pun) of smaller less efficient RPCs would cost more on both the application server and the database. Smaller simpler requests to fetch a large complex piece of data are less efficient than pulling it all at once. Smaller simpler requests to fetch a small percentage of a large complex piece of data may be more efficient. It's as simple as that, I'm afraid.

Posted by: Billy | Apr 19, 2006 8:40:24 AM

"It depends" is a classic hedge. I also don't have data, but it is also unclear what would be the valuable data for this discussion. What everyone seems to be dancing around is that AJAX is yet another design space and the scaling load of it is entirely dependent on the nature of the information being pooled, timeliness requires, constraints. A well-designed AJAX application should require less bandwidth and less load, but that may be because client-side processing is not the answer for doing the data filtering. It depends.

I expect that most of the readers of this blog could figure out both a high and low server load implementation for any AJAX application we might get data for.

Posted by: Dan Vogel | Apr 19, 2006 8:45:40 PM

Can we get someone to implement the (in)famous Pet Store sample app in ajax to do some benchmarking? :-)

Posted by: Bill Higgins | Apr 19, 2006 9:10:11 PM

I created the JSF AJAXable application several minutes ago:
before reading this discussion.

Faces Trace, just created by Cagatay Civici, clearly shows that AJAX requests requires much less time on the server than non-ajax request, even the AJAX request walks though the whole life-cycle.

Posted by: Sergey Smirnov | Apr 20, 2006 8:42:26 PM

...and just for the reference:
* Faces Trace is a new open source project announced by his author on the blog: http://jroller.com/page/cagataycivici?entry=facestrace_beta_is_out
* the demo application works under Exadel VCP framework: http://www.exadel.com/web/portal/products/VisualComponentPlatform

Posted by: Sergey Smirnov | Apr 20, 2006 8:46:05 PM

If you write just the same rectangular, forms-and-reports CRUD applications that we've all been writing since the early days of the CGI and add just a dash of AJAX, then yes, I think you can keep the overall traffic down.

AJAX, however, is going to move some of the document centric apps from the desktop to webapps (http://blogs.pathf.com/agileajax/2006/04/again_on_scalab.html), with all sorts of changes in development, architecture and so on.

I think there the lessons to learn from are from client/server, not n-tier J2EE.

Posted by: Dietrich Kappe | Apr 21, 2006 2:40:20 PM

Most importantly, however, is the fact that the interface between Ajax client and server application (whether it is written in Java, C#, PHP, or Ruby on Rails) is chosen by the application designer.

Posted by: ben | Jul 31, 2006 12:43:54 AM

Most importantly, however, is the fact that the interface between Ajax client and server application (whether it is written in Java, C#, PHP, or Ruby on Rails) is chosen by the application designer.


Posted by: ben | Jul 31, 2006 12:44:33 AM

Post a comment