How to wait for an asynchronous web service call result in ASP.NET for better performance

Question

In the ASP.NET WebForms website (IIS, the only application pool) I have a call to a long web service method that is referenced in Visual Studio as a Service Reference (.NET 4.0). Unfortunately, I have to wait for information from the web service before I can serve the page for the user. The web service is currently called synchronously, so the server cannot use the current thread to process other requests that have a performance impact.

Of course, I can generate asynchronous operations to refer to the service in Visual Studio and call BeginGetFoo instead of GetFoo , but still I have to somehow wait for the result from the web service.

That is the question. If I use AsyncWaitHandle.WaitOne (as shown below), would it be better to use all the application performance conditions from the synchronous call that I use today?

 IAsyncResult result = fooSoapClient.BeginGetFoo(); result.AsyncWaitHandle.WaitOne(); var foo = fooSoapClient.EndGetFoo(result); 

And of course, if waiting can be done better, I am open to suggestions.

Answer 1

You want to use an asynchronous page. See “ Evil Code: Scalable Applications with Asynchronous Programming in ASP.NET ”, and Asynchronous Pages in ASP.NET 2.0 for web services and asynchronous tasks with RegisterAsyncTask .

Answer 2

You will still invoke the thread. A “safe” option would be to use ASP.NET MVC async controllers: http://www.aaronstannard.com/post/2011/01/06/asynchonrous-controllers-ASPNET-mvc.aspx

Ideally, you should not work long in a web request. Do you have a Windows service or something that handles a long job (which could be caused by a web request, dropping something in a message queue or putting a task in a database) and polling from a client using ajax or something else, and then update the user when done.

Answer 3

If refactoring your code is unacceptable, so you cannot follow @John Saunders, then the only thing you can do is increase the number of threads for the application. This will allow you to scale better, but at some point it will have diminishing returns, and you will begin to hurt performance. Moreover, if you do not have users waiting for a request queue (i.e., more than 25 simultaneous users per kernel on your server), you do not need to do anything. Asynchronous programming on a web server only helps with scalability, but not with actual performance for a single user.