List Save is Slow

Liza posted on Tuesday, April 08, 2008

This is my first post so please be gentle!  I am writing an application to keep track of appointments.  An editable root list is bound to the schedule.  I am using the version just before 3.5.  My problem is that there may be 350 objects on the schedule and my save is slow.  I am using remoting.  My question is, when a list of 350 objects contains 2 objects that are dirty, how much of the list is transferred over the WAN to save those 2?  Does it transfer the list to the remoting site then execute Save() on the 2 dirty objects?  If so how would you recommend I deal with this? 

Code is like this:

//say this returns 500 objects
Appointments a = Appointments.GetAppointments(some criteria data);
//then through the course of operations say 2 get updated
.........
//now we save
a.ApplyEdit();
//this call goes to some www. remoting portal
a = a.Save();

 

Please help! 

Thanks.

Liza

Liza replied on Tuesday, April 08, 2008

HTTP compression is on on the server IIS btw.  Just forgot to mention that.

RikGarner replied on Thursday, April 10, 2008

Liza,

The thing to remember when remoting is that anything that happens inside a DataPortal_XXX method is happening on the server. It is likely that your list is being transferred to the server before being saved. Do you have a check in the DataPortal update to check if the objects are dirty?

Liza replied on Thursday, April 10, 2008

So my question is "How would you handle it?".  Assume we have 500 items in a read write root list.  Of those 500, 4 are dirty.  If when using Remoting the whole list is sent to the server and then saved, How could we get out those two, save, and remerge? them into the original list elegantly?  Is that even what I should do?  I could brute force it but I figure you guys being the experts, you probably have already dealt with this.

Thanks in advance!

Liz

stefan replied on Friday, April 11, 2008

Hi,

here is something that I am carrying in the back of my mind for quite some time, but haven't tested yet:

Create an object that contains
- a readonly list of readonly info objects;
This list is marked as <NonSerialized()> and is always accessed through a public readonly property.
When this property is called the first time (most probably by databinding), 500 objects are loaded into the child list. This would be the only time, when a great number of object data would go over the wire,
assuming that you wish to cache the list.

- an editable list containing your editable objects;
You would create Public ReadOnly Property for that list, and decorate that property with <Browsable(false)>, so that drag 'n drop databinding would omit it.
This list is for internal use only and not meant for databinding!
Nevertheless you will need that property if you want to implement ValidationRules that are triggered by list changes...
This child list is implemented in the standard manner, meaning that the Data Portal takes care of its persistence. It is empty by default!

Then, each time the user selects an item from the readonly list, you would tell your object to load the respective editable object, add it to the hidden editable list, and display it for editing. Before fetching the object from the server, you would check if it was already added to the editable list, and then display that one instead.
When you save, only those objects which were touched by the use case are sent to the server side.

I think this is a good example of an object serving as a Use-Case-Controller.

Depending on the kind of your editable objects (root or child) your editable list would inherit from
EditableRootListBase or just EditableListBase.

Hope that helps,

Stefan

Liza replied on Friday, April 11, 2008

That is a very interesting approach.  What I will have to resolve is rebuilding the list when a new item is added.  Should not be to hard though.  Very good.  I will tinker with that today.  Any other ideas?

RikGarner replied on Friday, April 11, 2008

I have used a technique similar to the one Stefan explains and it did work.

You might want to do a bit of experimenting before you go down that route to see if your performance problem really is with the transmission over the wire or with the database update. You could write some tests to compare the time taken to do a save when 4, 10, 40, 100, all the objects in the list are dirty. If you see the length of time taken increasing roughly in proportion to the number of dirty objects then your bottleneck is to do with writing to the database rather than moving the list to the server.

sergeyb replied on Friday, April 11, 2008