2

I came across a complex situation (imo) which is why I am asking this question. I am developing an application where in, I connect to all SharePoint Sites specified by user and all its sub sites using client object model. Now there is a client who have lots and lots of sub sites and their child sites. The total count goes easily into hundreds.

At the moment I simply read all the site structure on background thread during first load to allow my application to run normally. It still takes at least 50-60 seconds overall to test connection to each site and sub site. Now, I am thinking to add another background thread for each sub site at level 1, from where several questions arises.

Adding another thread would mean there would be more simultaneous connection to SharePoint Server from each user. Will there be a negative or sudden severe performance impact on SharePoint Server? Even though I will be making connection to different Site/Sub Site!

Then imagining a SharePoint Site with 200 sub sites, could initiating so many background threads at once create system issue or any problem?

I know I do not have best-est choice of words but I hope I made my self clear enough. Any suggestions would be very helpful and appreciated. Thanks

  • you can always limit the # of threads. instead of 200, use 20 at a time. whenever a thread finished, use it for another site. – urlreader May 23 '14 at 20:30
2

I've written this app several times (...as a matter of fact, working on one right now for a client). I'd recommend an on-demand approach. Develop the solution to have a configurable "cache to" value and cache up to that value...fetch everything beyond that on-demand. The cache could be based on a) tree depth...i.e. how deep do I go in the tree before I stop or b) node depth...i.e. how many entries in a node do I cache before I stop. I've done it both ways based on requirements. The advantage to the b (node depth) is there is something to display when the user accesses a node and you fetch the rest of the node in the background and display as you get it back from the server.

Hopefully you find the feedback valuable.

0

I would also recommend an asynchronous approach.

According to Understanding Key Design Decisions in SharePoint 2010 Development:

When you start to use the client object model, you often find that you cannot execute methods against the web server by using synchronous behavior. This is because a synchronous call ties up the primary UI thread and results in freezing the UI until the method call returns. It is generally unacceptable in application design to freeze the UI when making calls across the network.

In some cases it is prefeerable to utilize CSOM asynchronously by using the ClientContext.ExecuteQueryAsync method. When you call the ClientContext.ExecuteQueryAsync method, you must pass delegate references to callback methods. These callback methods execute when the call returns from the web server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.