Azure .NET CLR Test
By default, the Azure App Service uses the .NET framework to run ASP .NET applications. Issues impacting the stability of the framework therefore, can adversely impact the performance of and user experience with these applications. Such issues can include excessive heap memory usage on .NET, frequent garbage collection activities, improper loading of classes / assemblies / modules / AppDomains etc. When such issues occur, it is important for administrators to rapidly identify which worker process is experiencing such bottlenecks and why. Using the Azure .NET CLR test, administrators can monitor each worker process, keep an eye out for issues threatening the health of worker processes, and promptly alert administrators when such issues occur. This way, the test enables administrators to initiate measures to resolve the issues, so as to ensure the high availability and peak performance of .NET applications.
Target of the test :Microsoft Azure Apps Service
Agent deploying the test : A remote agent
Outputs of the test : One set of results for each worker process running on the .NET CLR
Parameter | Description |
---|---|
Test period |
How often should the test be executed |
Host |
The IP address of the host for which this test is to be configured. |
Port |
The port at which the specified Host listens. |
Tenant ID |
Specify the Directory ID of the Azure Active Directory that is associated with the subscription of the target Microsoft Azure. To know how to determine the Directory ID, refer to Configuring the eG Agent to Monitor the Microsoft Azure App Service. |
Client ID and Client Password |
The eG agent communicates with the target Microsoft Azure using JAVA API calls. To collect the required metrics, the eG agent requires an Access token in the form of an Application ID and the client secret value. To know more about determining the Application ID and the key refer to Configuring the eG Agent to Monitor the Microsoft Azure App Service. Specify the Application ID of the created Web Application in the Client ID text box and the client secret value in the Client Password text box. |
Enable System Classes |
By default, this test does not report detailed metrics for the Current system classes measure. Accordingly, this flag is set to No by default. In the event of a memory contention on the CLR however, you may want to know which classes are currently loaded on to the CLR and how much memory is consumed by each class, so that you can quickly identify the class that is hogging memory. For such useful memory usage insights, you need to first instruct the test to collect detailed diagnostics for the Current system classes measure. To achieve this, set the Enable System Classes flag to Yes. Before enabling this flag however, make sure that the following are in place:
|
Enable CLR Memory |
By default, this test does not report detailed metrics for the Total instancesmeasure. Accordingly, this flag is set to No by default. In the event of a memory contention on the CLR however, you may want to know the number of objects in and the total size of each class that is loaded on to the CLR. This will help you quickly identify those classes that are hogging memory and why - is it because they contain too many objects? or is it because they contain objects of a large size? For such useful insights into memory hogs, you need to first instruct the test to collect detailed diagnostics for the Total instances measure. To achieve this, set the Enable CLR Memory flag to Yes. Before enabling this flag however, make sure that the following are in place:
|
Max Classes in DD |
By default, the detailed diagnosis for the Current system classes and Current application classes measures, if enabled, report the top-10 classes in terms of size. If you want more or fewer classes to be displayed as part of detailed diagnostics, then change the value of this parameter accordingly. |
Max Modules in DD |
By default, the detailed diagnosis for the Current modules measure, if enabled, lists a maximum of 10 modules that are currently loaded on to the CLR. If you want more or fewer modules to be displayed as part of detailed diagnostics, then change the value of this parameter accordingly. |
Max Logical Threads in DD |
By default, the detailed diagnosis for the Current logical thread measure, if enabled, provides details of the top-10 logical threads in terms of their CPU usage. If you want more or fewer logical threads to be displayed as part of detailed diagnostics, then change the value of this parameter accordingly. |
DD Frequency |
Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency. |
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Number of worker processes |
Indicates the number of instances of this worker process. |
Number |
Every application executing on the .NET server corresponds to a worker process. Sometimes, during active or proactive recycling, a new worker process and the worker process that is being replaced may coexist. Under such circumstances, a single application might have multiple worker processes executing for it. |
CLR exceptions |
Indicates the total number of managed exceptions thrown per second by this worker process. |
Exceptions/Sec |
Exceptions are very costly and can severely degrade your application performance. A high value of this measure is therefore an indicator of potential performance issues. |
Gen 0 collections |
Indicates the number of objects collected during gen 1 collection (youngest; most recently allocated) since the start of this worker process. |
Number |
Use the detailed diagnosis of this measure to know when each Gen 0 collection started and ended and how many objects were collected during each collection. |
Gen 1 collections |
Indicates the number of objects collected during gen 1 collections since the start of this worker process. Objects that survive are promoted to generation 2. |
Number |
Use the detailed diagnosis of this measure to know when each Gen 1 collection started and ended and how many objects were collected during each collection / promoted from Gen 0. |
Gen 2 collections |
Indicates the number of objects collected during gen 2 collection since the start of this worker process. |
Number |
Generation 2 is the highest, thus objects that survive collection remain in generation 2. Gen 2 collections can be very expensive, especially if the size of the Gen 2 heap is huge. Use the detailed diagnosis of this measure to know when each Gen 2 collection started and ended and how many objects were collected during each collection / promoted from Gen 1 and Gen 0. |
Large object heap |
Indicates the number of large objects collected during garbage collection since the start of this worker process. |
Number |
The .NET garbage collector (GC) divides objects up into small and large objects. When an object is large, some of its attributes become more significant than if the object is small. For instance, compacting it—that is, copying it in memory elsewhere on the heap—can be expensive. Because of this, the garbage collector places large objects on the large object heap (LOH). If an object is greater than or equal to 85,000 bytes in size, it’s considered a large object. Small objects are always allocated in generation 0 and, depending on their lifetime, may be promoted to generation 1 or generation2. Large objects are always allocated in generation 2. This is because, they are collected only during a generation 2 collection. Use the detailed diagnosis of this measure to know when each LOHGen 2 collection started and ended and how many objects were collected during each collection. |
Time in GC |
Indicates the percentage of elapsed time that was spent in performing a garbage collection (GC) since the last GC cycle for this worker process |
Percent |
This measure is usually an indicator of the work done by the Garbage Collector on behalf of the application to collect and conserve memory. This measure is updated only at the end of every GC and the measure reflects the last observed value; its not an average. A value close to 100% is a cause for concern. This is because, every time a GC is performed, application performance degrades. Meaning, the longer GC operations are performed, application performance will also suffer longer. |
Classes loaded |
Indicates the cumulative number of classes loaded in all assemblies since the start of this worker process. |
Number |
|
Current system classes |
Indicates the number of system classes currently loaded by this worker process. |
Number |
Use the detailed diagnosis of this measure to know which system classes are currently loaded by the worker process and the size of each class. This will point you to classes that are hogging memory. |
Current application classes |
Indicates the number of application classes currently loaded by this worker process. |
Number |
Use the detailed diagnosis of this measure to know which application classes are currently loaded by the target worker process and the size of each class. This will point you to application classes that are hogging memory. |
Rate of classes loaded |
Indicates the rate at which this worker process loaded classes in all assemblies. |
Classes/Sec |
This counter is not an average over time; it displays the difference between the values observed in the last two samples divided by the duration of the sample interval. |
Assemblies loaded |
Indicates the total number of assemblies loaded by this work process. |
Number |
An assembly in ASP.NET is a collection of single-file or multiple files. The assembly that has more than one file contains either a dynamic link library (DLL) or an EXE file. The assembly also contains metadata that is known as assembly manifest. The assembly manifest contains data about the versioning requirements of the assembly, author name of the assembly, the security requirements that the assembly requires to run, and the various files that form part of the assembly. The biggest advantage of using ASP.NET Assemblies is that developers can create applications without interfering with other applications on the system. |
Assemblies loaded recently |
Indicates the number of assemblies currently loaded by this work process. |
Number |
If the Assembly is loaded as domain-neutral from multiple AppDomains then this counter is incremented once only. Assemblies can be loaded as domain-neutral when their code can be shared by all AppDomains or they can be loaded as domain-specific when their code is private to the AppDomain. To know which assemblies were loaded and module and appdomain each assembly belonged to, use the detailed diagnosis of this measure. |
Rate of assemblies |
Indicates the rate at which Assemblies were loaded by this work process. |
Assembles/Sec |
If the Assembly is loaded as domain-neutral from multiple AppDomains then this counter is incremented once only. Assemblies can be loaded as domain-neutral when their code can be shared by all AppDomains or they can be loaded as domain-specific when their code is private to the AppDomain. This counter is not an average over time; it displays the difference between the values observed in the last two samples divided by the duration of the sample interval. |
Failed assembly |
Indicates the number of assemblies that this work process failed to load. |
Number |
Ideally, the value of this measure should be 0. A non-zero value indicates that a work process failed to load one/more assemblies. |
Appdomains loaded recently |
Indicates the number of AppDomains loaded by this work process during the last measurement period. |
Number |
AppDomains (application domains) provide a secure and versatile unit of processing that the CLR can use to provide isolation between applications running in the same process. |
Appdomains loaded |
Indicates the number of AppDomains loaded by this work process during the last measurement period. |
Number |
|
Modules loaded |
Indicates the number of modules loaded since the start of this work process. |
Number |
|
Modules loaded recently |
Indicates the number of modules loaded by this work process during the last measurement period. |
Number |
Use the detailed diagnosis of this measure to know name, type, appdomain, and assembly of each module that is loaded. |
Rate of modules |
Indicates the rate at which this work process loaded modules. |
Modules/Sec |
|
Class load failures |
Indicates the number of classes this work process failed to load. |
Number |
Ideally, the value of this measure should be 0. A non-zero value indicates that a work process failed to load one/more classes. In this case, use the detailed diagnosis of this measure to know which classes failed. Load failures could be due to many reasons like inadequate security or illegal format. |
Rate of load failures |
Indicates the rate at which this work process failed to load classes. |
Failures/Sec |
Ideally, the value of this measure should be low. |
Current logical threads |
Indicates the number of current managed thread objects in the application. This measure maintains the count of both running and stopped threads. |
Number |
|
Heap memory usage |
Indicates the number of bytes committed by managed objects of this work process |
MB |
This is the sum of the large object heap and the generation 0, 1, and 2 heaps. |
Total instances |
Indicates the total number of objects in the classes loaded by this worker process. |
Number |
Use the detailed diagnosis of this measure to know which classes hold how many objects, and the total size in memory of each class. This will help you quickly identify those classes that are hogging memory and why - is it because they contain too many objects? or is it because they contain objects of a large size? |
Gen 0 size |
Indicates the heap memory used by gen 0 objects of this worker process. |
MB |
If the value of the Heap memory usage measure is abnormally high, then compare the value of this measure with that of the Gen 1 size, Gen 2 size, and LOH size measures to accurately isolate what type of objects is hogging the heap memory - gen 0 objects? gen 1 objects? gen 2 objects? or large objects? If this comparison reveals that gen 0 objects are draining heap memory, then you can use the detailed diagnosis of this measure to identify the precise classes that are hogging memory. |
Gen 1 size |
Indicates the heap memory used by gen 1 objects of this worker process. |
MB |
If the value of the Heap memory usage measure is abnormally high, then compare the value of this measure with that of the Gen 0 size, Gen 2 size, and LOH size measures to accurately isolate what type of objects is hogging the heap memory - gen 0 objects? gen 1 objects? gen 2 objects? or large objects? If this comparison reveals that gen 1 objects are draining heap memory, then you can use the detailed diagnosis of this measure to identify the precise classes that are hogging memory. |
Gen 2 size |
Indicates the heap memory used by gen 2 objects of this worker process. |
MB |
If the value of the Heap memory usage measure is abnormally high, then compare the value of this measure with that of the Gen 0 size, Gen 1 size, and LOH size measures to accurately isolate what type of objects is hogging the heap memory - gen 0 objects? gen 1 objects? gen 2 objects? or large objects? If this comparison reveals that gen 2 objects are draining heap memory, then you can use the detailed diagnosis of this measure to identify the precise classes that are hogging memory. |
LOH size |
Indicates the heap memory used by large objects of this worker process. |
MB |
If the value of the Heap memory usage measure is abnormally high, then compare the value of this measure with that of the Gen 0 size, Gen 1 size, and Gen 2 size size measures to accurately isolate what type of objects is hogging the heap memory - gen 0 objects? gen 1 objects? gen 2 objects? or large objects? If this comparison reveals that large objects are draining heap memory, then you can use the detailed diagnosis of this measure to identify the precise classes containing large objects. |
LOH allocated size |
Indicates the heap memory allocated to large objects of this worker process. |
MB |
If the value of the LOH size measure grows close to the value of this measure, it implies that large objects are rapidly eroding heap memory. You may want to allocate more heap to large objects in order to avoid the memory contention. |
LOH free size |
Indicates the amount of allocated heap memory still unused by large objects of this worker process. |
MB |
A high value is desired for this measure. |