I have a general Flex-to-CF performance question to pose and would love to get some feedback from the community.  

Current Behavior
I am working on an enterprise application that contains several 'screens' where users manipulate application data. There are a variety of ways in which a user manipulates the data but, for the purposes of this post, a commonly used approach entails a user dragging and dropping items to get them in a specific order. 

The current design responds each time a user drops an item in a spot. When that happens, events are fired to reorder the data based on the drag-drop and immediately send this new order to the CF server to update the data in a SQL Server database. 

Alternative Behavior
The alternative would be to add a button for the user to click when s/he is done ordering their items. When clicked, the appropriate events fire to record the order and send said data to the server. While dragging and dropping would remain how the user orders their data, the drop event would not fire any functions to send data to the server ... that would be reserved for the 'save' button.

Concern
There are a variety of places in the application where we send data back to the server on the fly in like manner to what I described above (Current Behavior). The concern is valid as, even without myriad concurrent users, the application is processor/server intensive. 

My concern is that, as we launch and the number of concurrent users rises, accessing the application and interacting with the data in our current manner may quickly overload the ColdFusion (v8.0.1) and SQL servers (SQL Server 2008) because I can see a lot of scenarios where users are constantly maniuplating data, changing their mind about what they did, re-manipulating the data, and so on. Basically, I worry that we'll end up in a situation where we are sending 100s or 1000s of asynchronous requests to the CF/SQL servers simultaneously and will crash or greatly reduce server/application performance. 

My thought was that requiring users to click a 'save' button (or whatever it may be labeled) before sending the data would alleviate some of the UI-Server communications and bandwidth. However, such a revised approach would, I think, negatively, though not significantly, affect usability.

Questions
Is it better to sacrifice a little usability in favor of reduced server traffic?
Am I off-base in my assessment of how the current behavior could affect the server? 

Any and all thoughts are welcome and thanks!!

Disclaimer
While I would love to chat about the application itself, I'm under an NDA and cannot (nothing unusual there!). Also, I want to clarify that I do not think there is anything wrong with our current approach and that my noting the application is server intensive is not a knock on the system at all. 

This is a really kick-ass application and I can't wait until it launches! And, I say that having had nothing to do with the conception, design, or development until this week, as I was just added to the team :).

Posted via email from Craig Kaminsky's posterous

Comments

Anonymous
Maybe make it work like autosave in gmail. Requests are queued up and pushed to the server every n seconds. before this auto-save activates, the save button is enabled. after the save occurs the save button is disabled, then re-enabled on the next change.
Mark
The best thing about the save option is that it also present a reset option. If your user plays with the order of items and then changes his mind, then choosing to not save resets the order as it was when he started.

Mark Fuqua
Craig Kaminsky
Thanks, Paul! I appreciate your response and am glad to hear that I'm not off-base in my concerns and possible alternative.
Paul Carney
This is a question we have also dealt with as we move from CF based UI to Flash using Flash Builder.

My belief is that the user should be able to manipulate items, like moving them around in a sort, without the actions being immediately stored. So, they should have to take an action to "save" what they have been playing with.

And you are correct - sending that many requests to the server as you ramp up in concurrent users will create more traffic than you really want.