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

Configurable parameters for the test
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: To report detailed metrics on system classes, this test uses the eG .NET Profiler. This is why, before enabling this flag, you need to make sure that the eG .NET Profiler is deployed on the .NET CLR and is configured to communicate with the eG remote agent that runs this test. To know how to install and configure the eG .NET Profiler, refer to Installing and Configuring the eG .NET Profiler on Azure. Detailed metrics collection is a resource-intensive exercise. You may sometimes notice that the eG agent consumes more memory when collecting detailed statistics on system classes. Hence, it would be good practice to configure the eG agent with adequate memory resources before enabling the detailed diagnostic capability.
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: To report detailed metrics on objects, this test uses the eG .NET Profiler. Before enabling the flag therefore, make sure that the eG .NET Profiler is deployed on the .NET CLR and is configured to communicate with the eG remote agent that runs this test. To know how to install and configure the eG .NET Profiler, refer to Installing and Configuring the eG .NET Profiler on Azure. Detailed metrics collection is a resource-intensive exercise. You may sometimes notice that the eG agent consumes more memory when collecting detailed statistics on garbage collection and large objects in memory. Hence, it would be good practice to configure the eG agent with adequate memory resources before enabling the detailed diagnostic capability.
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: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test
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.

Glossary

Azure .NET CLR Test