What is performance counter in .NET?
The Performance Counter is a Windows feature that allows you to record and publish system and application performance metrics.
Processes, threads, events, mutexes, and semaphores, as well as features of your own running programs, may all be monitored and analyzed using performance counters. They may assist you in identifying bottlenecks in your system and application, as well as fine-tuning system and application performance.
With a set of easy-to-use types, the.NET Framework supports performance counters. The Common Language Runtime (CLR) also provides its own collection of preconfigured counters.
Looking for more details about Performance Counter? Then this blog is all you need. Read on…
Table of contents
- What is performance counter in .NET?
- .NET CLR Performance Counters
- Performance Counters in the .NET framework
- Conclusion
What is performance counter in .NET?
A performance counter is a feature that measures your system's or application's performance. Metrics such as the number of active threads in a process or the value of elapsed time spent executing instructions by threads in a process are typical examples.
Categories are used to organize and group performance counters. The processor category, for example, contains all counters related to the processor's operation, such as processor time, idle time, interrupt time, and so on.
Windows includes a number of predefined performance counters that can be obtained programmatically or viewed in the Performance Monitor. These counters are used to keep track of how much operating system's resources are being used.
The CLR offers its own set of performance statistics in the.NET world. From exception handling to security checks, these cover every area of CLR functioning.
.NET CLR Performance Counters
To help you monitor and improve your application's performance, the.NET Common Language Runtime offers nine performance counter categories. A list of these categories, along with a brief description, can be found in the table below.
- Exceptions: This property contains information about the exceptions that your application has thrown.
- Interop: Information about how your application interacts with COM components, COM+ services, and type libraries is provided.
- JIT: The JIT compiler has compiled code and returns information about it.
- Loading: This property contains information about loaded assemblies, classes, and AppDomains.
- Locks and Threads: Provide information about your application's managed locks and threads.
- Memory: This page contains information on the garbage collector.
- Networking: Gives you information about the data your application sends and receives over the network.
- Remoting: Gives you information about the distant objects that your program uses.
- Security: This section describes the security tests that the CLR performs on your application.
There are far too many performance counters linked with these categories to list them all here. You may get more information about performance counters in the.NET Framework General Reference.
Other performance counter categories that aren't listed in the previous table or in the.NET Framework documentation may be installed on your machine (my installation also includes a Data category for monitoring SQL Server connections.)
ASP.NET exposes its own set of performance counters for people working with Web applications. See "Performance Counters for ASP.NET" in the.NET Framework Developer's Guide for more details.
Performance Counters in the .NET framework
Following are the different performance counters in the .NET framework:
Exception performance counter
# of Exceps Thrown: This is the total number of exceptions thrown after the application began. This contains both managed and unmanaged exceptions that have been converted to managed exceptions.
# of Exceps Thrown / Sec: This is the number of exceptions thrown per second. It contains both managed and unmanaged exceptions that have been converted to managed exceptions.
# of Filters / Sec: This is the number of .NET exception filters that are executed per second. Whether or not an exception is handled, an exception filter assesses it.
Interop performance counter
# of CCWs: This is the current number of COM Callable Wrappers(CCWs). A CCW is a proxy for a managed object that an unmanaged COM client references.
# of marshaling: This is the total number of times arguments and return values have been marshaled from managed to unmanaged code, and vice versa.
# of Stubs: This is the number of stubs created by the common language runtime.
JIT performance counter
# of IL Bytes JITted: Since the application began, the just-in-time (JIT) compiler has compiled the entire quantity of Microsoft intermediate language (MSIL) bytes.
# of Methods JITted: Since the application began, the total number of methods JIT-compiled has been displayed. Pre-JIT-compiled techniques are not included in this counter.
% Time in Jit: Since the last JIT compilation phase, this value shows the proportion of time spent in JIT compilation.
Loading performance counter
Bytes in Loader Heap: This is the current size of the memory committed by the class loader across all application domains.
Current appdomains: This is the number of application domains loaded in the application.
Current Assemblies: This is the number of assemblies loaded in the currently running program across all application domains.
Locks and Threads performance counter
# of current logical Threads: This is the number of currently managed thread objects in the application.
# of current physical Threads: This is the number of native operating system threads that the common language runtime has created and owns to operate as underlying threads for managed thread objects.
# of current recognized threads: This is the number of threads currently detected by the runtime.
Memory performance counter
# Bytes in all Heaps: This is the sum of the counters for Gen 1 Heap Size, Gen 2 Heap Size, and Large Object Heap Size.
# GC Handles: This is the current number of garbage collection handles in use.
# Gen 0 Collections: This is the number of times generation 0 objects (that is, the newest, most recently allocated objects) have been trash collected since the application began.
Networking performance counter
Bytes Received: This is the total number of bytes received by all Socket objects within the AppDomain, since the operation began.
Bytes Sent: This is the total quantity of bytes transferred by all Socket objects within the AppDomain, since the operation began,
Connections Established: This is the total number of Socket objects for stream sockets that have ever been connected within the AppDomain, since the process began.
Security performance counter
# Link Time Checks: This is the total number of link-time code access security checks that have been displayed since the application began.
% Time in RT checks: This is the percentage of time spent conducting runtime code access security checks since the last sample.
Stack Walk Depth: This is the stack depth during the latest runtime code access security check.
Conclusion
We constantly evaluate the performance of our code (applications, services, drivers, and so on) in a testing environment. Then we'll be able to diagnose and fix problems in the future. We may publish, capture, and analyze the performance statistics of running code using performance counters. There are a lot of counters in each category some of which were mentioned in this post.