In his blog, Billy Newport talks about how AJAX has advanced the state of website development. He also goes on to point out that this advancement is not without it's costs. To do it's job AJAX enabled applications interact with the server a lot more frequently then normal web applications do.

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.

In analyzing how AJAX works, Billy observed that as good as lazy fetching was from a users point of view, this must implemented carefully. Too many fetches asking for very small datasets can over burden an application server. When that happens the server will not be as responsive. This effect will negate the advantages of using AJAX.

Each call to the server has fixed overhead. Each fetch from the database has a fixed cost. RPCs that request small amounts of data generate the highest overhead in these terms. If they were combined to fetch larger blocks of data with fewer requests then the overhead is lower.

The net result is that developers have to be mindful of these two stressors as they integrate AJAX into their web enabled applications. As a final thought, Billy acknowledges the advancement offered by AJAX but opines that it is time to start talking about patterns for developers to follow. Since patterns come out of an aggregation of similar use cases, we can start the process of identifying potential patterns by asking; are you using AJAX today and if so how is it being used?

I wrote up a possible pattern for Ajax development on my blog to use a JMS queue to allow for scalability. However, to reduce the burden on application servers, it might be best to redirect Ajax queries against a separate server rather than the main one, so you don't overload the main server.

Using GZIP encoding (which is supported by most browsers) we recently sped up an AJAX app by simply preloading all the data. The entire dataset was >800K (JSON encoded) but compressed down to only 40K.

Something to consider..

You can use a servlet filter to do the GZip encoding so it doesn't get intermixed with your code. However, you need a more powerful server to handle the compression load.

Bill Newport makes a very valid point, which I have personally experienced in an SVG prototype application. I have created a air traffic monitoring system for many cities. You may se one of a older version at (if you have Adobe’s SVG plug-in already installed):
http://www.cbsdf.com/technologies/jsp/atc_test1a.jsp

In this application, each Air Plane goes to server to get its new location, to move its self on the map. (Please be patient, I am hosting this on low cost budget server). Please make sure that all the cities are loaded, by selecting Radio-buttons.

The overhead is awful (so I have to increase pooling interval to move the flights). When I change this, so that one small JavaScript function gets locations of all the flights and updates them, there is substantial performance improvement. Brief back ground on the sample application at: http://www.cbsdf.com/misc_docs/gui-api-brief.htm

In the real world case such approach results in unacceptable locking at backend side.

I figure you're assuming pessimistic locking, right? Optimistic locking means avoiding the locks at the expense of

1) Stale reads (data not protected by locks)
2) Transaction rollbacks because of collisions.

But, it's provides a lot more concurrency and probably lowers the load on the backend but you do pay for over qualified updates on flush/commit, of course which isn't free.

I used nearly hundred Flights and multiple people viewing same web page in LAN and not encountered Backend locking. I even used 3 seconds time interval to move flights for better effect. But on the web, I have to use 8 or 10 seconds (I don’t remember now).
http://www.cbsdf.com/misc_docs/gui-api-brief.htm
for five cities: http://www.cbsdf.com/technologies/jsp/atc_test1.jsp.

I just start working on some more GUI Controls, which need locking and confirmation (both write and read back) that the change is actually taken in effect at the Server or actual device. For example, user may change by 10 units using knob, but it may only increased by 5 units (e.g. hit max limit or whatever), and which must be communicated back to the GUI Component to display the new settings properly.
http://www.cbsdf.com/technologies/misc-docs/Scales-Dials-Meters.htm

The flight location is just read-only, so doesn’t need any locking. But occasionally, I have seen receiving the out of order locations (when I user 3 minutes interval). That is, location for first request reaching after already updating location for the later request. This results in a momentary move back. So if it is fatal, we can maintain a count of the request and ignore responses from older requests. Also when you click on a flight, it is taking few seconds to see the Information table for the flight in the above web page.

Regards,
Raju

I think part of this concern over how AJAX is being used and implemented is that our current style of webapp development is leaving each developer out there on his own to craft a solution from scratch or with one or more frameworks. Reminds me of the olden days when people would handcraft graphical interfaces on the Apple, C64 and PC. We don't do that anymore.

We also shouldn't develop single-page applications with clumsy, multi-page frameworks.

Component GUI's, either server side (Echo2) or client side (OpenLaszlo for DHTML or Tibco's GI), will both boost productivity for developing AJAX/RIA and improve the quality of the underlying implementations. Batching AJAX messages, filtering meaningless client-side events, using GZip and/or JSON, using COMET should all be run-time configuration options of the framework.

I prefer the server-side approach because it keeps you from leaking out business logic, though in high-latency, low-bandwith situations, using a client side component framework may be better.