Wednesday, November 22, 2006
Upstream data caching in AJAX applications
To date, the obvious implementation of server-side caching has been to store frequently-accessed data downstream - archiving information in a memory-based container to reduce expensive roundtrips to a formal data store like a database server or XML file. This makes read-only requests for HTTP-GET transactions efficient in providing fast access while conserving server resources for other operations. But I'm going to now discuss a reverse condition: employing caching for upstream situations - specifically managing data for AJAX web applications utilizing form submissions via HTTP-POST.
I was hacking together an internal utility to generate real-time scores for sports broadcasts, which will serve as the feed source for TV graphics. (A variation of this app is discussed here.) The user interface is a simple HTML form with text fields and input buttons to increment/decrement score values, modifying the value of a DIV via DOM manipulation. This is coupled with an AJAX process periodically submitting the form in the background to an ASP.NET script that reads the POST values and uploads the data to a database for storage. What I noticed is that despite the nature of a live sports data to change rapidly, the AJAX operation is called quite often (about every 10 seconds), but the DB doesn't need to be updated every single time. So the app becomes more efficient by making such updates conditional.
Using the .NET Cache API, I store the form's text field values in a custom object and place this in the Cache. Then, when the AJAX gradual upload process sends data across the wire, I do simple string comparison, testing the equality between the items in Cache and the current values of the scores from the form. If the values are the same, any modification operation is canceled and resources aren't unnecessarily wasted. If there's new data, the Cache entry is invalidated and rehydrated with the fresh data, and an UPDATE SQL statement via a sproc is executed.
More and more, models of this kind are becoming popular with people doing clever things with AJAX and responsibly wanting to manage server memory, disk space and bandwidth. It also proves there are many more uses for sever caching that just downstream.
Code forthcoming...
I was hacking together an internal utility to generate real-time scores for sports broadcasts, which will serve as the feed source for TV graphics. (A variation of this app is discussed here.) The user interface is a simple HTML form with text fields and input buttons to increment/decrement score values, modifying the value of a DIV via DOM manipulation. This is coupled with an AJAX process periodically submitting the form in the background to an ASP.NET script that reads the POST values and uploads the data to a database for storage. What I noticed is that despite the nature of a live sports data to change rapidly, the AJAX operation is called quite often (about every 10 seconds), but the DB doesn't need to be updated every single time. So the app becomes more efficient by making such updates conditional.
Using the .NET Cache API, I store the form's text field values in a custom object and place this in the Cache. Then, when the AJAX gradual upload process sends data across the wire, I do simple string comparison, testing the equality between the items in Cache and the current values of the scores from the form. If the values are the same, any modification operation is canceled and resources aren't unnecessarily wasted. If there's new data, the Cache entry is invalidated and rehydrated with the fresh data, and an UPDATE SQL statement via a sproc is executed.
More and more, models of this kind are becoming popular with people doing clever things with AJAX and responsibly wanting to manage server memory, disk space and bandwidth. It also proves there are many more uses for sever caching that just downstream.
Code forthcoming...
Subscribe to Posts [Atom]
Post a Comment