scalability in client object model vs web services

Question

I have a app in which I need to query a sharepoint site via services. The app will be under heavy usage so performance and scalability will be two of my priorities.

I started to investigate which service approach is better and from a perf point of view it seems that client object model is the one officially suggested, but when I came to scalability I personally found that actually web services seem more potent than client object model. This is because it seems that web services have async support for IO bound operations rather than client object model that doesn't. I say doesn't because as Stephen Toub said the ability to invoke a synchronous method asynchronously does nothing for scalability and I think BeginInvoke does just that.

I have to mention that I am using in my app C# 5 async/await feature in order to return the thread to the thread pool when queries are executed on the server.

My question is, what should weight more in order to take a decision?

Edit: It is worth to mention that I am not using the Silverlight CSOM, I am using the more generic .NET one.

Answer 1

This is an answer with no answer. :)

You are correct in that BeginInvoke is fake-asynchronous (i.e., it just issues the blocking call on a thread pool thread). So it would actually be worse, scalability-wise, than just invoking the blocking methods.

First, consider your scalability as compared to your Sharepoint server. If you're running on roughly equivalent hardware, then you probably don't need to scale any more than the Sharepoint server will. You would probably be fine with either solution.

If you do need to scale better (e.g., the Sharepoint server is a cluster or cloud, or if your machine is much lesser than the Sharepoint machine), then it requires more thought and likely testing.

The better performance in the client model is purely from its batching capabilities. So if your application won't use batching, then the (asynchronous) web services model would be better.

However, if your application uses batching and needs to scale better, then there isn't an answer. In this case, the only way to know is to build a test case both ways and measure it.

Answer 2

Actually, the client object model not only provides, but sometimes requires asynchronous access. You can find more info in the Data Retrieval Overview but the short version is that:

1. You create and load one or more queries in a ClientRuntimeContext then
2. Execute all loaded queries either synchronously with ClientRuntimeContext.ExecuteQuery or asynchronously with ClientRuntimeContext.ExecuteQueryAsync with two callbacks for success or failure

You don't have to use BeginInvoke anywhere.

In fact, the Client object model in Silverlight provides only the Async method in which case you are forced to execute the call asynchronously.

The syntax is quirky, but the client object model targets .NET 3.5 and Silverlight, so it wasn't possible to provide a Task based interface. You can even argue that callbacks are somewhat simpler than the Begin/End pattern and definitelly better that raising completion events.

EDIT

As @alexb noticed, ExecuteQueryAsync is available only in Silverlight. There are other ways to work asynchronously though.

You can take advantage of Sharepoint's OData support to query lists using WCF Data Services. The query scenario is a bit similar, as you submit your query and wait for a callback when the results come in. In the meantime, you get access to a DataServiceQuery object that represents the asynchronous query.

This method uses REST/Json and therefore lighter on the wire than the web services. The LINQ and ORM-like API are also easier to work with compared to the web services.

Sharepoint's support is described in Query SharePoint Foundation with ADO.NET Data Services and asynchronous querying is described in How to: Execute Asynchronous Data Service Queries (WCF Data Services)