A year or two ago, I worked on an AJAX-type application (before AJAX was buzzword du jour) used within the company for monitoring messages flowing through a number of applications. The app began life as a set of simple web pages, automatically refreshing at regular intervals, displaying a few new messages at the top of a table. It wasn’t the ideal solution, but a quick and dirty addition, to get something up and running in a hurry. Especially quick and dirty when you consider a page of 50 – 100 messages was being redisplayed (unnecessarily) with each refresh.

A better solution would be to only deliver new messages — which is where AJAX comes into the picture. Under the covers, the application was about 70% REST interfacing, so plugging in XmlHttpRequest to retrieve the latest message, insert it at the top of the table and drop a message off the bottom, was a relatively straightforward task (and thank goodness for browser standards which removed IE from the equation…. .

Consider a table of 100 messages, 500 bytes per row (I can’t recall the exact size, since there were href’s and javascript events on each row as well as just data); average page size, with other associated gumpf to make the page useful, would be around 60-80K. Somewhere in the region of 2MB of data every minute with 3 client machines requesting a page refresh every 5 seconds. (Apologies up front if I’ve miscalculated here, but I’m recovering from the flu… still destroying small forests every time I sneeze).

The AJAX version, assuming 1K for a request to get a single new message — ~400 bytes to retrieve a basic 404 error page when there are no new messages — means, at worst, ~40K per minute for the 3 clients, based on the original 5 second refresh rate, and increasing the rate to a more “real-time friendly” 2 requests per second, is still only around 370K per minute.
20% of the traffic, and an application that suddenly looks more performant because you’re not waiting for an entire page to load. Seemed like a win-win.

One factor I failed to fully take into consideration, was that the client machines were on a separate network (and separate internet connection). >2MB of html page-based data transferred each minute was a significant bottleneck, also taking into account various other factors of that particular environment, so the operators were never actually keeping up with the volume of messages coming through the system. With a refresh that wasn’t limited by delivering an entire page, they decreased the delay time… and decreased… and decreased… and finally set it to zero, watching messages come through as fast as the system could deliver them. Meaning that rather than a massive decrease in bandwidth usage, traffic actually went up. Significantly.

We were already delivering something in the region of 2.6 million requests per day, so an additional 1 million requests was easy to absorb from a server load perspective (albeit this represents a 40% increase in requests, it was well within capabilities) — so rather than causing problems with server load, we had issues with bandwidth utilisation (always an pain in NZ), and the fact that usage patterns suddenly changed.

Which is actually a long-winded way of saying that I agree with Tim, that AJAX costs depend entirely on what you’re doing. Server load isn’t the main issue — the challenge comes from usage, and your assumptions and expectations regarding that usage.

Or at least, I hope that’s what I’m saying. I’m a bit light-headed from the sneezing. A better question at the moment should probably be, what happens when you sneeze hard in the Matrix? Do you sneeze in the real world? I bloody well hope the Machines designed those capsules with some tolerance for pressure differentials….