AJAX is making the Web run faster

16 02 2006

A very interesting article by Tim Bray on the real benefit of AJAX:

I suspect there’s a huge system-wide optimization waiting out there for us to grab, by pushing as much of the templating and page generation work out there onto the clients. In particular, when you’re personalizing a page, assign all the work you can to the personal computer sitting in front of the person in question. Yeah, that cool, responsive AJAXy stuff is nice but maybe it’s the icing on the cake; the real win is making the Web run faster.

That’s mostly true, but I suspect there are some downsides as well. The most obvious one is that not all browsers are AJAX-ready and if you want to cater to those, you’ll have to go through hoops in order to provide people using them with the same user experience level, which will probably complicate your life as a programmer just a little bit.

A second downside is that AJAX makes it really easy to write web pages that can hog a server much more than a traditional template processing step will ever be able to do. I can already see AJAX widgets constantly polling servers for updated data (news tickers, etc.) and possibly keeping server sockets tied for a long time, which is a usage pattern that most servers were not designed to cope well with.

Greg Wilkins wrote about this issue some time ago:

But there is a new problem. The advent of AJAX as a web application model is significantly changing the traffic profile seen on the server side. Because AJAX servers cannot deliver asynchronous events to the client, the AJAX client must poll for events on the server. To avoid a busy polling loop, AJAX servers will often hold onto a poll request until either there is an event or a timeout occurs. Thus an idle AJAX application will have an outstanding request waiting on the server which can be used to send a response to the client the instant an asynchronous event occurs. This is a great technique, but it breaks the thread-per-request model, because now every client will have a request outstanding in the server. Thus the server again needs to have one or more threads for every client and again there are problems scaling to thousands of simultaneous users.

To sum it up, I have some doubts that having a server process a large number of small requests will be more efficient than having it process a dynamic template, given that you can often design your dynamic pages to be cache-friendly and put a fat, reverse proxying cache in front of the server. Edge Side Includes are also promising in this respect.

What Tim is doing on ongoing is fine, but the potential for abuse by less cautious web developers is high.




One response

16 02 2006
James Strachan

I guess its a server-side CPU versus server-side sockets issue.

Sockets are often cheap (depending on if you need hardware SSL or not) whereas significant server side CPU can sometimes eat up lots of power. Though CPUs are getting multi-core and lower power so I guess the power use is going down.

Certainly server side OSes need to be optimised to support lots of concurrent sockets efficiently (like the new solaris does) then the Ajax cost will be minimised.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: