Profiling ASP.NET vNext using dotMemory and dotTrace
With ASP.NET vNext (working title), Microsoft is making some bold moves towards opening up development and deployment options for building applications. For starters, we no longer have to install the full .NET framework on our servers: ASP.NET vNext lets us deploy our own version of .NET on an app-by-app basis. Next, the project model is being migrated to being just a project.json file describing dependencies and some optional configuration, much like we write apps in NodeJS.
ASP.NET vNext is still in an early preview, but it never hurts to explore and test-drive what’s going to be the next generation of .NET. And when writing code for it, we may want to inspect performance and memory of our applications to verify we don’t have any issues there. And what better tools than dotMemory and dotTrace to do that?
Setting the correct CLR type
Before we start profiling, it is important to know that profiling currently only works when the Desktop CLR is active. The new Core CLR does not (yet?) expose the same profiler hooks.
Checking if the correct CLR is active can be done from the command line using the kvm list command.
Make sure that the active CLR (marked with an *) shows the svr50 runtime. If it’s svrc50 that means we’re on the Core CLR and have to switch to the Desktop CLR using the kvm set <pick the correct version from the above list> command.
Attaching to an already running ASP.NET vNext process
After starting dotMemory or dotTrace, hit Attach To Process on the toolbar. This will give us a list of all running processes on our local computer. Both profilers can also attach to processes running on remote machines. From this list, find the klr.exe process. When running multiple ASP.NET vNext applications on our machine, it will be a bit tricky to find the correct one.
We can provide additional options and even make use of the profiler API in our ASP.NET vNext applications. Hitting Run will attach the profiler which will behave identical to profiling “classic” .NET applications. For example in dotMemory, we can see the memory usage (unmanaged and managed heaps) in real-time:
In dotTrace we can see the subsystems used by our code and drill down to the function or thread level.
Starting an ASP.NET vNext process with profiling enabled
When attaching to an already running process, some options will be unavailable. For example, dotMemory will be unable to collect memory traffic for an already running application. It will be impossible to pick a more detailed profiling mode for dotTrace, such as Tracing or Line-by-Line profiling. For these options to be available, we have to launch the process with profiling enabled from the start.
Running ASP.NET vNext applications is done using the k run or k web commands. These are aliases for the active runtime which is located under %USERPROFILE%\.kre\packages\<seleced runtime>\. From dotMemory and dotTrace, we can use the Profile | Standalone Application menu and enter the startup details for our ASP,NET vNext application.
Here’s what we have to specify:
- Application: the ASP.NET vNext runtime to use. This will depend on which runtimes we have installed on or system but will look like %USERPROFILE%\.kre\packages\<seleced runtime>\bin\K.cmd.
- Arguments: the arguments we would typically pass to the k command. If we start our application with k web, then web would be the argument to specify here.
- Working directory is the path where our application and its project.json file are located.
Using this approach, we can now set all additional profiler options. dotMemory allows collecting memory traffic while dotTrace will let us perform Line-by-Line profiling and specify the measure used. Run will launch the application and lets us capture a snapshot we can investigate later.
Give it a try! Even with a new CLR in town we still have to care about memory and performance of our applications. Here are some resources to get started with dotMemory and dotTrace:
- ASP.NET vNext information and tutorials at www.asp.net/vnext
- Download dotMemory and explore the tutorials
- Download dotTrace and checkout the tutorials
Subscribe to Blog updates
Thanks, we've got you!
Another Look into the Future with Rider’s Predictive Debugger
In the 2023.2 release cycle, we’ve introduced the Predictive Debugger in ReSharper, which gives you predictions about code paths and variables beyond the current execution pointer. We’ve written extensively about its advantages compared to alternative debugging strategies like thorough thinking, log…
Visualize Entity Framework Relationships and Additional Query Analysis in ReSharper 2023.3
A lot of teams are using Entity Framework or EF Core to work with their database. As an Object-Relational Mapper (ORM), it bridges objects in code to a relational database model, so that as a developer you don’t have to worry too much about the actual database. We all know: that’s not entirely tr…
Automatically Analyze ASP.NET Core Performance With Dynamic Program Analysis
Slow web pages may make your users or customers abandon your web application, even before they’ve had a proper look at it. You’ve likely also been frustrated working with a web application that is slow to load. The good news is that the latest versions of ReSharper and JetBrains Rider’s Dynamic P…
OSS Power-Ups: MassTransit – Webinar Recording
The recording of our webinar, OSS Power-Ups: MassTransit, with Chris Patterson, is available. This was the thirteenth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webinars.…