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.
If you want to improve it, you need to measure it. We use profiling tools to get the insight required to find and destroy application bottlenecks. I’m a big fan of local profiling tools that you can install and run from within your application. My favorites are Miniprofiler and Glimpse. Unfortunately, many of the tools that are available on regular ASP.NET are not available for ASP.NET Core. In this post, we’re going to explore our options for local profiling in ASP.NET Core. Currently, it’s slim pickings, but there are a few tools available.
For standard ASP.NET (non-core) Applications, there are a variety of profiling tools available. Some of those tools cost money and others are free. Unfortunately, most of them lack ASP.NET Core support. This is, in part, because ASP.NET Core is new. Additionally, our good friends at Microsoft have thrown the community a few curve-balls with the last few versions of the .NET Core. Most companies don’t want to waste their time building tools if the framework is going to have a ton of breaking changes. This is especially true for free tools.
Here’s the status of a few popular tools (as of January 2017):
The folks at Stack Overflow are waiting for a more stable version .NET Core to build their .NET core version of Miniprofiler. They said they will build a new version, but they only want to do it once.
JetBrains has not released a .NET Core version of dotTrace, though they claim some functionality with the current version. I’ve never tried this one, so I have no idea if it’s worth waiting for.
I love Glimpse. It’s one of my favorite profiling tools. The folks behind Glimpse put out a Beta version of Glimpse about a year ago. It lacked full functionality and no longer works. They appear to be working on the new version now. Their GitHub repo has recent check ins, so I’m hoping a new version appears soon.
This is Microsoft’s default solution for application performance monitoring. It’s meant to be used in conjunction with Azure, but you can run it locally and use Visual Studio to look at the results. Once hooked up to Azure, you can use this as a general application performance monitoring (APM) tool. It’s installed by default in new ASP.NET Core Projects (look at the startup.cs), so Microsoft really wants you to use it. I kicked the tires a bit. Prefix is a competent option for ASP.NET Core.
Application Insights in action:
Stackify prefix is a free tool you can install on your PC that monitors your ASP.NET applications. You’ll need to also install it in your project, but once you do so, you get access to detailed information about your application’s requests. They have a paid version of the Prefix and a related APM product, so there’s some commercial backing here. I’ve tried out Prefix a few times and the tool is adequate for local profiling. It gives you the data you need, but I’m not a huge fan of the development experience. That being said, the tool gives you access to lots of data and works on .NET Core.
Stackify Prefix in action:
I’m still waiting for a new version of Glimpse (or Miniprofiler), but Stackify Prefix and Application Insights are good tools. I miss the easy to use inline monitoring of Glimpse, but Prefix and Application Insights have their advantages. Not only are they supported on .NET core, they also hook into more robust monitoring systems. You will be well served by either option. Go forth and monitor your apps, it’ll save you a lot of pain down the road.