Scaling WCF service which makes Http calls

I have a WCF service hosted in IIS which is an adapter for various ThirdParty APIs. All this service does is: - accept a synchronous operation call from GUI - fire a synchronous Http Request to third party - convert the result to canonical format - return to GUI

In practice it spends most of the waiting on network i/o to complete. What is the best pattern to make such service scale while maintaining synchronous interface for the GUI? I know that for ASP.NET apps that have a lot of i/o it is recommen开发者_如何学运维ded to use async handlers to free-up the thread executing request.

Is there any good pattern for WCF?

Thanks, Piotr

As you have described, this is a potential scalability issue.

ASP.NET has a thread pool that (last time I checked was 250 but could increase up to 1000 - configurable but above 1000 not really recommendable) serves requests. HTTP requests in ASP.NET have thread-affinity so there is a one-to-one relationship between these threads and requests.

When you call externals services, requests thread keeps hanging and if you run out of threads, your client will receive a 503 error.

Solution for scaling this service would normally include a request by the client to start the operation and then client would continuously poll the service to see if it has finished. If you implement these services as light-weight and efficient, you lose a bit of performance but gain so much scalability.

You would also need to think about:

• Storing the result so that the client can get it.
• Discarding the result if the client does not get back to the server for the result.

I have come across this "AsyncPattern" which may be the solution to this problem (http://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.asyncpattern.aspx)

I looks like a way to “free-up” the service thread while it’s waiting on the I/O to be completed.At the same time it preserves the synchronous nature of the operation from the caller perspective (i.e. this is strictly service side implementation detail). The disadvantage appears to be code complexity on the service side: all the external call’outs must use Begin/End API.

Some useful links: What is the use of "AsyncPattern" property of "OperationContractAttribute" + wcf? WCF - AsyncPattern Performance http://blogs.msdn.com/b/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx