Profiling

The second package I recommend that developers install into any ASP.NET MVC application is the MiniProfiler (http://miniprofiler.com/) set of packages. Once installed and properly configured, MiniProfiler adds a little widget to every page on your site when running in localhost. You can find it in the top-left corner, as shown in Figure 16.5.

Figure 16.5

Click on the widget and you'll get profiling information for the current page. For example, Figure 16.6 shows that the search page for the NuGet Gallery runs two SQL queries. You can also see timing information for the queries, as well as timing information for certain key points in the request life cycle, such as rendered views and partial views.

Figure 16.6

Code that uses Entity Framework, an ORM, can make it difficult to know exactly what SQL is generated and run against the database. MiniProfiler exposes that information. Simply click on the “sql” links to see the generated SQL, as well as the containing method, as shown in Figure 16.7.

Figure 16.7

To set this up for an ASP.NET MVC application with Entity Framework, install MiniProfiler, MiniProfiler.EF, and MiniProfiler.MVC. After installing the package, there's a little bit of configuration required. Look in the AppActivator.cs file to see the configuration for the NuGet Gallery. Most of it is in the MiniProfilerPreStart and MiniProfilerPostStart methods as well as in the private MiniProfilerStartupModule HTTP module class.

Let's look at the first method:

private static void MiniProfilerPreStart()
{
    MiniProfilerEF.Initialize();
    DynamicModuleUtility.RegisterModule(typeof(MiniProfilerStartupModule));
    GlobalFilters.Filters.Add(new ProfilingActionFilter());
}

The first line of this method sets up MiniProfiler for Entity Framework Code First. If you're not using Code First, or using something other than Entity Framework, you'll need to read the MiniProfiler documentation to find out how to configure it to log SQL queries.

The second line registers the custom HTTP Module, MiniProfilerStartupModule, via code. Prior to ASP.NET 4, the only way to register an HTTP module was to add some configuration to Web.config. MiniProfilerStartupModule controls when and how profiling works. At the time of this writing, it only profiles the application when it is accessed via the local host. However, there is some code in there to enable it for administrators, but that's currently commented out. The code here is similar to the code that the MiniProfiler docs suggest placing in Application_BeginRequest and Application_EndRequest.

The last line of this method adds a global action filter used to profile actions in an ASP.NET MVC application.

Let's move on to the second method:

private static void MiniProfilerPostStart()
{
    var copy = ViewEngines.Engines.ToList();
    ViewEngines.Engines.Clear();
    foreach (var item in copy)
        ViewEngines.Engines.Add(new ProfilingViewEngine(item));
}

This method wraps every view engine in the application with a profiling view engine. This allows MiniProfiler to provide rich information about how long views and partial views take to be rendered.

With this small bit of configuration, MiniProfiler can profile a lot of information about your application. It doesn't profile every method call, as that would be too invasive, but it does provide a lot of useful information. There may be cases where you want some more information. Perhaps a certain code path is extremely hot and you'd like to see how long it takes in production. MiniProfiler also provides an API that allows you to instrument and profile your code at any granularity you choose.

The MiniProfiler is not a substitute for all code profiling and performance measurement tools. However, the fact that it's free, takes just a few minutes to install and configure, and provides a user experience that's very easy to use and understand justifies my recommendation that app developers should have it high on their list of NuGet packages to use in their applications.