To determine whether your .Net application meets its performance objectives (and wins the race) and to help identify bottlenecks, you need to measure your application’s performance and collect metrics. Metrics of particular interest tend to be response time, throughput, and resource utilization (how much CPU, memory, disk I/O, and network bandwidth your application consumes while performing its tasks).
Let’s start by taking a look at the tools and techniques that are available to collect performance data for your .NET application.
Tools and Techniques
You might need to collect data during prototyping, application development, performance testing, and tuning, and in a production environment. The following tools and techniques can help you to collect performance data:
· System and platform metrics
· Network monitoring tools
· Profiling tools
· Tools for analyzing log files
· Application instrumentation
We won’t go into these tools in detail as they go beyond the scope of this article and most of them are standard tools that come with development tools such as Visual Studio.
Application Instrumentation
In addition to the available profiling and monitoring tools, you can instrument your code for capturing application-specific information. This form of information is much more fine-grained than that provided by standard system performance counters. It is also a great way to capture metrics around specific application scenarios.
For example, instrumentation enables you to measure how long it takes to add an item to a shopping cart, or how long it takes to validate a credit card number. There are a number of ways that you can instrument your code. These are summarized in the next section, and each approach is expanded upon in subsequent sections.
Instrumentation
Instrumentation is the process of adding code to your application to generate events to allow you to monitor application health and performance. The events are generally logged to an appropriate event source and can be monitored by suitable monitoring tools such as MOM. An event is a notification of some action.
Instrumentation allows you to perform various tasks:
- Profile applications. Profiling enables you to identify how long a particular method or operation takes to run and how efficient it is in terms of CPU and memory resource usage.
- Collect custom data. This might include custom performance counters that you use to monitor application-specific activity, such as how long it takes to place an order.
- Trace code. This allows you to understand the application code path and all the methods run for a particular use case.
You can use various tools and technologies to help you instrument your application. The right choice depends on your development platform, logging frequency, the volume of data being logged, and how you plan to monitor. You have several options:
· Event Tracing for Windows (ETW)
· Window Management Instrumentation (WMI)
· Custom performance counters
· Enterprise Instrumentation Framework (EIF)
· Trace and Debug classes
The various options available for logging are suitable for different scenarios. The following questions help you make an informed choice:
- What do you want to accomplish with instrumentation?
There are various goals for instrumentation. For example, if you need only debugging and tracing features, you might use these features mostly in a test environment where performance is not an issue. But if you plan to log the business actions performed by each user, this is very important from a performance point of view and needs to be considered at design time.
If you need to trace and log activity, you need to opt for a tool that lets you specify various levels of instrumentation through a configuration file.
- How frequently do you need to log events?
Frequency of logging is one of the most important factors that help you decide the right choice of the instrumentation tool for you. For example, the event log is suitable only for very low-frequency events, whereas a custom log file or ETW is more suitable for high-frequency logging. The custom performance counters are best for long-term trending such as week-long stress tests.
- Is your instrumentation configurable?
In a real-life scenario for an application, you might want to instrument it so the data collected is helpful in various application stages, such as development (debugging/tracing), system testing, tuning, and capacity planning.
All the code stubs for generating the data need to be inserted in the application during the development stage of the life cycle. The code stubs for generating such a huge amount of data may themselves add to performance overhead. However, in most scenarios, it is a small subset of data that you are interested in during a particular stage of the life cycle. You need configurable instrumentation so the relevant set can be turned on at will to minimize performance overhead.
Based on the preceding considerations, the usage scenarios for the various options are as follows.
Event Tracing for Windows (ETW)
ETW is suitable for logging high-frequency events such as errors, warnings or audits. The frequency of logging can be in hundreds of thousands of events each second in a running application. This is ideal for server applications that log the business actions performed by the users. The amount of logging done may be high, depending on the number of concurrent users connected to the server.
Windows Management Instrumentation (WMI)
Windows Management Instrumentation is the core management technology built into the Windows operating system. WMI supports a very wide range of management tools that lets you analyze the data collected for your application.
Logging to a WMI sink is more expensive than other sinks, so you should generally do so only for critical and high-visibility events such as a system driver failure.
Custom Performance Counters
You can use custom counters to time key scenarios within your application. For example, you can use a custom counter to time how long order placement takes or how long it takes to retrieve customer records.
Enterprise Instrumentation Framework (EIF)
EIF permits .NET applications to be instrumented to publish a broad spectrum of information such as errors, warnings, audits, diagnostic events, and business-specific events. You can configure which events you generate and where the events go, to the Windows Event Log service or SQL Server, for example. EIF encapsulates the functionality of ETW, the Event Log service, and WMI. EIF is suitable for large enterprise applications where you need various logging levels in your application across the tiers. EIF also provides you a configuration file where you can turn on or turn off the switch for logging of a particular counter.
EIF also has an important feature of request tracing that enables you to trace business processes or application services by following an execution path for an application spanning multiple physical tiers.
Trace and Debug Classes
The Trace and Debug classes allow you to add functionality in your application mostly for debugging and tracing purposes.
The code added using the Debug class is relevant for debug builds of the application. You can print the debugging information and check logic for assertions for various regular expressions in your code. You can write the debug information by registering a particular listener, as shown in the following code sample.
public static void Main(string[] args){
Debug.Listeners.Add(new TextWriterTraceListener(Console.Out));
Debug.AutoFlush = true;
Debug.WriteLine(“Entering Main”);
Debug.WriteLine(“Exiting Main”);
}
The code stubs added using the Trace class are enabled for both the debug and release builds of the application. The Trace class can be used to isolate problems by enabling the trace through the execution code path.
In Visual Studio .NET, tracing is enabled by default. When using the command line build for C# source code, you need to add /d:Trace flag for the compiler or #define TRACE in the source code to enable tracing. For Visual Basic .NET source code you need to add /d:TRACE=True for the command line compiler. The following code sample uses the Trace class for adding the tracing feature in your code.
public static void Main(string[] args){
Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
Trace.AutoFlush = true;
Trace.WriteLine(“Entering Main”);
Trace.WriteLine(“Exiting Main”);
}
Stay tuned to our series on how to improve .NET apps performance to learn more.
The post Is your .NET application ready for a race? appeared first on Monitis Blog.