The hidden costs of lazy fetch with AJAX

AJAX is an amazing improvement for web sites. I use the various google apps daily. But, some patterns employed by programmers may have hidden consequences on server sizing and server application architecture.

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.

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.

Client applications will have to be carefully coded to balance data per RPC and server overhead. It's a juggling game. There is no right answer but clearly, app by app, the developers need to make choices. The other thing to realize is that this isn't a new problem. JDBC programmers know this issue well. Many small transactions can be a big performance problem. If you can batch to reduce transaction frequency and increase data density is a no brainer for sometimes 10x performance gains. The same realization applies to AJAX development. It's no different.

Products like the ObjectGrid can help with the backend load by caching frequently used data thus shielding the database and client state needed for performance reasons on the server could be stored in an ObjectGrid also, thus making it available with distributed locking to the entire cluster.

I think it's clear the AJAX represents a big leap forward in web app usability. Now, it's time to start talking about patterns for the client/server development and while stateless servers are pushed a lot, I don't think they will work for all scenarios just as that pattern didn't work for all applications with J2EE. However, a cluster of stateless servers with a memory replicated storage grid backing it up may offer a better architecture for some applications.

Comments

[Josh Peters]

I think this post is a bit more realistic than yesterday's :)

In the end though, it's really nothing new: unless you understand a technology you cannot expect to weild it well.

AJAX opens the doors to new and useful applications (Google Suggest still rocks my socks) but unless the developers of such applications understand the impact of their toolkits they potentially waste resources.

Consider if Google Suggest and Google Video Search married into some new "Google Smart Video Search". Every stroke of a key in the search box could return dozens of Flash objects. Such an application could potentially be really useful, but at the cost of a great number of computing resources.

You hit the nail on the head that effective caching needs to take place, but this isn't any new advice either--large applications utilize caching, plain and simple.

[Billy]

Thanks for the kind words, Josh :)

Well, I got asked yesterday to back it up hence this one. I think you've hit a homer with the caching statement. Advanced caching is going to be a must for this and typically, the built in caches in application servers are not going to work, especially in rich media cases as you mentioned in your comment. Caches need to be able to scale to hold many Gb's or more of data. Of course, I'm pushing ObjectGrid as that fabric but all players will benefit as AJAX is increasingly adopted.

[Archimedes Trajano]

I wrote up a possible pattern for Ajax development on my blog to use a JMS queue to allow for horizontal 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.

To solve the issue of lots of small data retrieval, the javascript can retrieve more than one event in one request from the queue.