I’m a huge fan of ASP.NET Core. It’s a great iteration on the ASP.NET platform and it should be your default choice for any new web development. I’m also a big fan of apps that don’t take a week to load. Fortunately, ASP.NET Core doesn’t skimp in the speed department. The framework has some great features for building fast applications. Some things that used to be hard are now easy.
In this post, I’m going to go over a few tips for building blazing fast ASP.NET applications.
One important way to help your application scale is to use asynchronous methods. The async and await keywords make building asynchronous code as easy as building synchronous code. Using async and await frees up your threads while waiting for calls to return. Because you are using up fewer threads, more people can use your application at the same time.
Async is usually a good default practice. But, it’s especially important when calling slower processes, like database calls and service requests. You don’t want to hog up a thread waiting around for database results to come back. When building your application favor async versions when they are available. Entity Framework has async versions of most data access methods, so make use of them.
One thing to keep in mind is that using async and await will help you scale, but it won’t run your requests in parallel. If you have several slow requests, consider running them in parallel using the Task Parallel Library. That will compress your wait time to the longest running call, as opposed to waiting for each one to return sequentially.
Getting data out of a database is the largest performance bottleneck in most applications. One way to reduce that cost is to cache things that are slow to retrieve or slow to change. ASP.NET Core has a few built in cache mechanisms.
The easiest cache to use is the built in memory cache. This cache stores items in the memory of your applications server. While this is easy to use, there are two downsides. The first downside is your cache goes away if your server goes down. Often, this is a non-issue, but if your application caches things are costly to calculate, this can be a real downer. The second problem is that if you want to scale your application to more than one server, your’re out of luck.
The solution to this problem is to use a distributed cache. This cache uses either a REDIS instance or a SQL Server table to hold your cached data. I’ve used both flavors and they both work great. One thing I liked about using the SQL Server cache is that I could add fields to the table to enable more detailed caching logic.
Regardless of which caching mechanism you use, you should hide it behind your own cache abstraction. (I call mine ICacheProvider) By using your own cache abstraction, you can easily swap out one caching mechanism for another. Most people start off with the memory caching, but eventually outgrow it. If you put your caching behind an abstraction, you can swap it out for a distributed cache without having to change a bunch of places in your app.
By default, ASP.NET only compresses a few types of requests by default. These include the content of Razor pages, but not the results of api calls (JSON is not compressed by default). This means that if you have an api request heavy application (ie. a SPA), you can save some serious bandwidth by compressing those responses. This is especially important if you are serving mobile customers, who may have a low bandwidth signal.
Unlike the previous version of ASP.NET, Core has a handy built in middleware that you can add to your app. You can specify the type of compression and what mime types to compress. I’ve tested this in my application and the compression saves a noticeable amount of bandwidth.
If you have a good performance tip, feel free to leave it in the comments.