This talk was given by Rick Strahl.
What is considered a long running request? When it overruns the max thread pool, is CPU intensive and runs for more than a couple seconds, or it has a high user count.
There are 100 threads per CPU in the ASP.NET request pool. This works differently if you’re using IIS6 or IIS7. With IIS6, threads originate with ISAPI. Win32 native threads are fed into the ASP.NET engine, then released back to IIS. With IIS7, there is an integrated pipeline. IIS threads fire directly into the ASP.NET pipeline. There is no difference between an IIS and ASP.NET thread.
There are several scenarios (solutions) Rick talked about, to handle long requests.
Scenario 1: The app is busy interface.
This is basically a "fake it" solution. You do something silly like disable buttons and show a progress bar to people know there is something happening but have to sit and wait. You disable the interface so the user doesn’t click again. A new click will cancel the current request on the client and start a new one. The request on the server will keep running though, and take up resources.
Scenario 2: Async processing.
This works well for I/O bound processing, but not for CPU bound processing. ASP.NET (2.0+) has things build in to make this easy. You can use page async tasks, and async operation callbacks. This will return the thread to the pool while waiting. When the request comes back, it grab the thread from the pool, and continue. Basically your page will run it’s course while the async stuff is happening, but won’t be rendered until all async tasks have returned.
Personally, I think this is a nice way to do it. You can keep firing off new async events when another finishes, so if there is a request that takes some time during the async work, the other requests won’t be affected by it.
Scenario 3: Threads and delegates.
This works well in the run and forget scenarios. ASP.NET disconnects from the thread, and continues processing the page, including rendering the page. If there is a task that you don’t want to block your page from rending, and you don’t need any information back from it, such as logging or writing something to SQL, this is a great way to do it.
Scenario 4: Background scheduling.
You can queue your requests or have non ASP.NET threads do the work. He didn’t talk much about this option. It doesn’t seem like something that would be used all that often.
Scenario 5: Async messaging.
You can use message based communication. Store your message somewhere, like SQL, and check back to see if the task is completed. This would be used in conjunction with the "app is busy interface" method.
If you have a site that uses services, is CPU or I/O intensive, or is just slow, Rick had several good ways of possibly speeding up your application. There are other things to consider also. If you’re using SQL, make sure indexes are set correctly, queries are optimized, and if you’re db is hit hard, putting the db and the log on separate drives, or even going as far as writes and reads are in separate db’s.
If you want to know more about async pages in ASP.NET there is a good MSDN article on it.