Production ASP.NET MVC applications need performance telemetry to answer basic operational questions: which actions are slow? Are request times degrading? Are certain endpoints throwing errors? Are key business metrics (sign-ups per hour, orders per minute) where expected?<\/b><\/p>\n\n\n\n
This article walks through implementing each of 3 instrumentation approaches: custom counters via PerformanceCounter class, ASP.NET MVC action filters for per-action timing, and Application Insights SDK integration for production telemetry. <\/b><\/p>\n\n\n\n
Note: <\/strong>For modern .NET applications (ASP.NET Core on .NET 6+), the equivalent ecosystem is OpenTelemetry (vendor-neutral observability standard), Application Insights still works, and additional options (Prometheus + Grafana, Datadog .NET Tracer) are commonly used. The instrumentation patterns (action filters, middleware, custom metric definition) transfer conceptually.<\/em><\/p>\n\n\n\n
\n
As application developers, we are always interested in performance. Applications today are more complex, support more users and are more essential to the daily operation of most enterprises than even a few years ago. This means that we are in a permanent state of needing better tools and better data to monitor the usage, performance and health of the applications we build. While it is still important to profile, load test and stress-test applications, we would also like to have a way to collect detailed performance data about an application while it is running in production. Why is this so? There are several good reasons.<\/p>\n
\n
You gain actual data of how your application is performing in production<\/em>. This data can help you to understand what features are most frequently used so you then know where to focus your future performance tuning efforts.<\/li>\n
You can establish a baseline of how your application performs under normal conditions. Knowing what is normal will then help you to understand when the health and performance of the application starts to trend yellow or enter red.<\/li>\n
When a performance problem happens, you will have the necessary detailed performance data in place to quickly diagnose it.<\/li>\n
You can understand usage trends that vary during the day or from day to day by instrumenting your application. The data will show if there is a certain time when usage spikes, and help you understand if you have enough capacity to handle these peak-load events.<\/li>\n<\/ul>\n
Most applications contain very little instrumentation for usage or performance. If we are fortunate, there may be a few log statements scattered throughout the application. A better solution would be to develop a consistent approach that could be applied across the application, making sure that a baseline set of metrics is collected for each major action that the application performs. As it turns out, the design of the ASP.NET MVC framework makes this easy. This article will show how to do it.<\/p>\n
In designing a solution, you’ll probably have these goals.<\/p>\n
\n
The solution should be easy to apply across the project. If it requires a developer to do something every time that an action or controller is added, then it is doomed to failure.<\/li>\n
The solution should not only be easy to implement in new applications that we are creating but also easy to retrofit to existing applications.<\/li>\n
The code that tracks performance must be cleanly separated from the application code. It is good practice in any design to keep different concerns separated, and there is no good reason to mingle the performance tracking code with the application logic.<\/li>\n
Performance data should be formatted to make it easy to collect and analyze using existing toolsets. This facilitates a single view of the data across the entire technology stack and allows existing reporting and alerting tools to be used.<\/li>\n
Although we’d want to track data across the application, the application developer does not necessarily want to track performance in some places. So the solution should be designed to allow the developer to opt out of certain actions.<\/li>\n<\/ul>\n
An overview of the solution is shown in the figure below.<\/p>\n
In the ASP.NET MVC framework, custom action filters allow an application developer to intercept calls to controller actions and add pre and post processing steps to the action.\u00a0 In this way, action filters provide a way to implement cross cutting concerns like logging or security in a module that is defined independently of the application code.\u00a0 In this design, a custom action filter named MvcPerformanceAttribute<\/code> is responsible for intercepting calls to controller actions and provides the entry point for where the performance of a controller action can be measured.<\/p>\n
When an incoming request is received, the OnActionExecuting()<\/code> method will create a PerformanceTracker<\/code> object and attach it to request.\u00a0 The PerformanceTracker<\/code> object is responsible for measuring how long the execution of the action takes and coordinating the update of the custom performance counters.\u00a0 After attaching the PerformanceTracker<\/code> object to the request, the ProcessActionStart()<\/code> method of the PerformanceTracker<\/code> object is called to start measuring performance.\u00a0 After the controller action has completed, the outbound response will again pass through the MvcPerformanceAttribute<\/code>, this time through the OnActionExecuted()<\/code> method.\u00a0 This method will extract the PerformanceTracker<\/code> object off of the request and call the ProcessActionComplete()<\/code> method.\u00a0 Calling this method indicates that the performance measurement is complete and the appropriate performance counters will be updated.<\/p>\n
Updating the custom performance counter objects is accomplished by making use of a collection of objects that derive from the PerformanceMetricBase class<\/code>. \u00a0These objects hold a reference to the performance counter(s) they are responsible for updating, and take care of the details of how to accomplish the update.\u00a0 By delegating the responsibility for the actual update of counters into a separate set of objects, the solution allows for future extensibility and keeps the process of updating the counters decoupled from the PerformanceTracker<\/code> object.\u00a0 If a developer wishes to add an additional counter in the future, the simply write a new class that derives from PerformanceMetricBase<\/code> and have it added to the collection.\u00a0 They do not need to edit the internals of the PerformanceTracker <\/code> class.<\/p>\n
![\"1889-clip_image002-630x469.jpg\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1889-clip_image002-630x469.jpg\")
<\/figure>\n![\"1889-clip_image003-630x372.jpg\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1889-clip_image003-630x372.jpg\")
<\/a><\/figure>\n![\"1889-clip_image004-630x384.jpg\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/imported\/1889-clip_image004-630x384.jpg\")
<\/figure>\n