Why you should use async tasks in .NET 4.5 and Entity Framework 6

Improve response times and handle more users with parallel processing

Building a web application using non blocking calls to the data layer is a great way to increase the scalability of your system. Performing a task asynchronously frees up the worker thread to accept another request while work is being done in the background. Until recently, designing your system this way was significantly more complicated. With the .NET framework 4.5 and Entity Framework 6, the task has become trivial.

Six TED Talks that can change your career

These talks will help you reshape how you approach work and see your career in a new light.

READ NOW

If you’re starting out building a new ASP .NET MVC 5 application, the new best practice is to use Async tasks for basically everything, unless you have a good reason to do otherwise. Your view controllers can be implemented as async methods, your generic collections have async functions, and with EF6, your data layer can take advantage of the technique as well. This functionality has existed in different forms in the past (PLINQ, Task Parallel Library, etc.) but the coding overhead and added thread management caused many to opt out from implementing it. Today, the System.Threading.Tasks library greatly simplifies the process.

In a .NET web application running on an IIS server, the application pool for the app only has so many threads it can spin up to use for request handling. When a user makes a request for a relatively long running task, the synchronous thread will begin to execute and will be blocked while it’s waiting for data to return, let’s say from an IO operation. If a new request comes in during that time, a new thread will be required to fulfill that request as the existing thread is waiting on IO. Spinning up these new threads requires additional memory and processing, and if your application is heavily used the app pool can quickly run out of available threads and result in an unresponsive application or even a timeout error for the user.

With asynchronous tasks, once the thread reaches the long running task that you’ve called asynchronously, the thread will be released and become available to process further requests while the task is being executed. This will keep your application responsive to the user and it will be able to accommodate significantly more simultaneous requests. In terms of benchmarked performance, I’ve seen load tests show 300% improvement in response times and concurrent connections boost almost 8x [I can’t find the link, but I promise I saw it] over the synchronous counterparts.

It’s not a silver bullet however. There is a time and place for async tasks, knowing when not to use them is just as important as knowing when you should. For a low level guide on how it works, have a look at this MSDN article detailing the process. Basically, the rule of thumb is to use an async task when your operation is accessing a slow medium like the network, disk, or database. If your operation is using data that you know is already in memory (memory stream, cached object, etc.), you’re better off using a synchronous task. Another vital consideration is that async tasks are not thread safe and they are not compatible with lazy loading. To keep your code from imploding, you need to ensure that you never execute two async tasks in parallel using the same data context. You also need to make sure you eager load / include any relational data your object might have to fetch from your async call.

There are some caveats, and even though it’s suggested that you use async tasks as the de facto going forward, you need to consider your application thoroughly before diving in. The performance benefits are too great to ignore, so while it may add a bit of complexity to your software, it should pay off in spades when a few thousand people decide to use it at the same time. Pay close attention to the functions you use it on, structure your data layer in a way that promotes compartmentalization of the context, and know when to use a synchronous call instead. With those things in mind you should be on your way to providing a snappy user experience and software your server administrators will love.

PREVIOUS POST

3 reasons to use code first design with Entity Framework

NEXT POST

Does relying on an IDE for development make you a bad programmer?

Matthew Mombrea

Matthew Mombrea is a software engineer, founder ofCypress North, and a technology enthusiast.

The opinions expressed in this blog are those of the author and do not necessarily represent those of ITworld, its parent, subsidiary or affiliated companies.