views:

122

answers:

2

Hi,

We're in the throws of redesigning a screen from "old style" edit and submit, to AJAXy style with auto saving every few seconds.

The result will be way more, but way smaller server/db round trips. For example as a user edits a textarea field, we'll autosave their changes every 60 seconds via AJAX. Currently they would update one or more such fields and then submit the whole page, and the whole page would reload.

We're doing this to make the page much snappier for the user - an obvious use of AJAX. But have any of you encountered server/db performance issues related to moving to an approach like this? Are there pitfalls it would be good to be aware of upfront from a server/db roundtrip perspective?

Thanks

+2  A: 

I mentioned this issue in this answer relating to DWR (a Java AJAX framework).

AJAX is seductive in what it offers. You will (most likely) get more data round-tripping (in terms of individual requests/responses). My advice is to monitor/measure this, and determine what is important to use in an AJAX context, and how expensive the round-tripping is (in network and CPU terms). As you've identified, this will impact your server processes and the backing databases.

You may find caching is required for various data types, or some data is simply too expensive to retrieve from the POV of an AJAX infrastructure. You can cache at the server end and (or course) in the web page itself.

I've seen client sites implement sizable amounts of AJAX-enabled web pages, only to have to restrict it or roll it back, due to the unforeseen impact on the back-end. With a little awareness and some effort in monitoring the impact this can often be avoided, or at least understood in advance and mitigated appropriately.

Brian Agnew
Load test the heck out of your application in your dev/staging environments, too, to make sure that your app will scale gracefully. Also, depending on your environment, something like Google Gears/local DOM storage can be used to save progress at intervals on the client side, with a final "save" push doing the same thing your original form was doing; something to look at from a performance standpoint.
ajm
A: 

I have never run into performance issues by letting the system, rather than the user, decide when it is appropriate to save something to a database.

I might imagine some issues of data integrity, but I take it those aren't important to you.