Is this a good candidate for using Asynchronous controllers in ASP.NET MVC

All the images in my site are served by a con开发者_开发问答troller action. This action checks to see if the image exists on disk and can do some manipulations (resizing etc.).

Considering that a page may contain 50 or so images, resulting in 50 requests, is this a good candidate for using ASP.NET MVC Async controllers?

You should read measure-the-performace-of-async-controllers first.

From the article

• Asynchronous requests are useful, but only if you need to handle more concurrent requests than you have worker threads. Otherwise, synchronous requests are better just because they let you write simpler code.
  (There is an exception: ASP.NET dynamically adjusts the worker thread pool between its minimum and maximum size limits, and if you have a sudden spike in traffic, it can take several minutes for it to notice and create new worker threads. During that time your app may have only a handful of worker threads, and many requests may time out. The reason I gradually adjusted the traffic level over a 30-minute period was to give ASP.NET enough time to adapt. Asynchronous requests are better than synchronous requests at handling sudden traffic spikes, though such spikes don’t happen often in reality.)

• Even if you use asynchronous requests, your capacity is limited by the capacity of any external services you rely upon. Obvious, really, but until you measure it you might not realise how those external services are configured.

• It’s not shown on the graph, but if you have a queue of requests going into ASP.NET, then the queue delay affects all requests – not just the ones involving expensive I/O. This means the entire site feels slow to all users. Under the right circumstances, asynchronous requests can avoid this site-wide slowdown by not forcing the other requests to queue so much.