Detailed description of ASP. NET performance monitoring parameters and asp.net Parameters

Detailed description of ASP. NET performance monitoring parameters and asp.net Parameters
Performance Monitor

Performance Monitor is a Windows system resource and performance monitoring tool. the Performance Monitor can quantitatively provide information such as CPU usage, memory allocation, abnormal distribution, and thread scheduling frequency. ASP. NET can provide the number of requests per second, the request response time, and so on. the Performance Monitor can monitor the utilization of the above resources over a period of time and provide average and peak values.

The performance monitor helps you obtain specific performance metrics and monitor system resource changes when a problem occurs. by checking the changes of some important counters in the Performance Monitor, we can often find some useful clues. for example, compare ASP. NET requests per second, whether the request response time and CPU utilization have the same change curve can see whether the performance is related to the load.

When solving performance problems, customers are often asked to add the following counters for performance collection.

• All counters under Process object
• All counters under Processor object
• All counters under System object
• All counters under Memory object
• If the client program is a. NET program, all counters under the object starting with. NET will be added.
• If you use ASP. NET, all counters under the object starting with ASP. NET will be added.

When analyzing Performance Logs, focus on the following counters.

Process object

==================

The counters in the Process object can analyze the memory, CPU, thread count, and handle count of the target Process based on the target Process, and then analyze the following counters of the target Process.

% Processor Time

-------------------

This counter is a metric of CPU resources occupied by the process. even if the process is busy, the average CPU usage should be less than 80%. if this value is exceeded, it can be considered that the program has a high CPU problem. another problem is that the CPU fluctuates greatly. although the average usage is not high, the ups and downs are frequent. in a short period of time, consecutive high CPU usage occurs.

Handle Count

------------------

This counter records the number of kernel object handle used by the current process. kernel object is an important system resource. when the program enters the stable running state, the number of Handle Count should also be maintained in a stable interval. if Handle Count shows a continuous upward trend throughout the entire program cycle, consider whether the program has Handle Leak.

ID Process

------------------

This counter records the ID of the process of the target process. You may find it strange that the ID has something to observe? The process ID is used to check whether a program is restarted. for example, ASP. NET workflow may be automatically recycled. because the process names are the same, only the process ID can be used to determine whether a restart occurs. if the ID changes, check whether the program crashes or Recycle.

Private Bytes

------------------

This counter records the number of Memory records that are currently performed through the VirtualAlloc API. whether it is the memory applied for directly calling the API, the memory applied by the Heap Manager, or the managed heap of the CLR, it is included. like Handle Count, if the overall trend continuously increases throughout the program cycle, it indicates that there is a Memory Leak.

Virtual Bytes

------------------

This counter records the total user-state memory addresses successfully applied for by the current process, including the addresses occupied by DLL/EXE and the number of memory addresses Reserve through the VirtualAlloc API, therefore, this counter should always be larger than Private Bytes. generally, the changes of Virtual Bytes and Private Bytes are roughly the same. because of the existence of memory fragments, Virtual Bytes and Private Bytes generally maintain a relatively stable proportional relationship. when the ratio of Virtual Bytes to Private Bytes is greater than 2, the program usually has serious memory address fragments.

Processor object

====================

Processor object records the load of chips in the system. Because normal programs cannot be bound to a specific CPU for execution, it is sufficient to observe the Total Instance on multiple CPU machines.

% Processor Time

----------------------

This counter has the same meaning as % Processor Time in Process. However, what is recorded here is not for a specific Process, but for the entire system. by comparing the counter with the counter of the same name in the Process, we can see whether the high CPU problem of the system is caused by a single Process.

System object

====================

The System object records the overall statistical information of the System. Therefore, instances are not distinguished. Some clues are often seen by comparing the changing trend of counter and other counter in the System object.

Context Switch/sec

--------------------

Context Switch indicates the scheduling of the entire thread in the system and the switching frequency. thread switching is a costly operation. frequent thread switching leads to a waste of CPU cycles. therefore, when you see a high CPU, you must compare it with the Context Switch. if the two have the same trend of change, high CPU is often caused by contention (line competition), rather than an endless loop.

Exception Dispatches/sec

-------------------

Exception Dispatches indicates the distribution of exceptions in the system and the handling frequency. Like thread switching, Exception handling also requires a lot of CPU overhead. The analysis method is the same as Context Swith.

File Data Operations/sec

-------------------

File Data Operations records the frequency of reading and writing disk files in the current system. by observing the changing trend of this counter and other performance pointers, you can determine whether disk file operations are performance bottlenecks. similar counters include Network Interface, Bytes Total/sec

Memory Object

==================

Memory object records the overall Memory statistics of the current system.

Avaiable Mbytes and Committed Bytes

---------------------

Available Mbytes records the number of physical memory remaining. Committed Bytes records the number of commit memories of all processes. Combined with two counters, we can observe that:

Free System Page Table Entries, Pool Paged Bytes and Pool Nonpaged Bytes

--------------------

The three counters can be used to measure the number of idle memory in the core state. especially when the/3 GB switch is used, the core-state memory address is compressed, which may easily lead to insufficient core-state memory and lead to some very strange problems.

. Net clr Memory object

==================

. Net clr Memory object records CLR-related Memory information in the CLR process. all the counters in this category are interesting and straightforward. we recommend that you use an example program for testing and research. the following are the two most commonly used counters.

Bytes in all heaps

----------------------

Bytes in all heaps records the memory space occupied by all CLR objects that cannot be recycled in the process during the last GC occurrence. this counter is not real-time. It is updated only when GC occurs. compared with Private Bytes in the Process of the same Process, the changes of managed heap and native memory can be distinguished. for memory leak, it is easy to distinguish between the leak of managed heap and the leak of native memory.

% Time in GC

% Time in GC records GC occurrence frequency. generally, less than 15% is normal. if the number exceeds 20%, GC occurs too frequently. GC not only brings high CPU overhead, but also needs to suspend the CLR thread of the target process. Therefore, high-frequency GC is very dangerous. compared with CPU utilization and other performance indicators, we can often see the impact of GC on performance. high-frequency GC is often caused:

Detailed description of performance monitoring parameters

ASP. NET supports two sets of performance counters: system and application. The former is made public in PerfMon of the ASP. NET performance counter object, and the latter is made public in ASP. NET Applications performance object. ASP. the State Server Sessions counters in the. NET performance object (only applicable to the Server computers in which the Server is running) and ASP. the Sessions counters in the NET Applications performance object (only applicable to user Sessions occurring in processes) differ greatly.

When monitoring the performance of ASP. NET Web applications, you should always keep track of the performance counters listed in the following table.

Performance object	Performance counters
ASP. NET	Application Restarts
ASP. NET	Requests Queued
ASP. NET	Worker Process Restarts
ASP. NET Applications	Errors Total
ASP. NET Applications	Requests/Sec
Processor	% CPU Utilization

ASP. NET system performance counters

ASP. NET supports the following ASP. NET system performance counters. They collect information about all ASP. NET applications on the Web server computer, or they are generally applied to the systems of ASP. NET servers running the same application. They may contain Web sites and Web parks.

Performance object	Counter	Instance	Description
Processor)	% Processor Time (Processor Time percentage)	_ Total	"% Processor Time" monitors the CPU usage of computers running Web servers. Low CPU utilization or failure to maximize CPU usage (no matter how much client load is) indicates that there is competition or lock for resources in the Web application.
Process)	% Processor Time (Processor Time percentage)	Aspnet_wp or w3wp (depending on the IIS Version)	Percentage of CPU time used by ASP. NET workers. When comparing the performance under the standard load with the previously captured benchmark, if the value of this counter drops, the requirement for the processor is reduced and the scalability is also improved.
Process)	Working Set)	Aspnet_wp or w3wp (depending on the IIS Version)	The number of memories actively used by ASP. NET. Although application developers have maximum control over the amount of memory used by the application, the system administrator can adjust the session timeout period to significantly affect this.
Process)	Private Bytes (Private byte)	Aspnet_wp or w3wp (depending on the IIS Version)	Private Bytes is the amount of memory (in Bytes) that is currently allocated to the process and cannot be shared by other processes ). The occasional spikes indicate that there are bottlenecks in some places, which may cause the worker process to continue holding the memory that is no longer needed. If this counter suddenly drops to a value close to 0, it may indicate that the ASP. NET application was restarted due to unexpected issues. To verify this, monitor the "ASP. NET Application Restarts" counter.
ASP. NET Applications (ASP. NET Applications)	Requests/Sec (number of Requests per second)	_ Total	You can check whether the request processing speed is suitable for sending speed. If the number of requests per second is lower than the number of requests generated per second, queuing will occur. This usually means that the request speed has exceeded the maximum.
ASP. NET Applications (ASP. NET Applications)	Errors Total (Total error count)	_ Total	The total number of errors that occur during HTTP request execution. Includes any analyzer, compilation, or runtime errors. This counter is the sum of "Errors During Compilation" (number of Compilation Errors), "Errors During Preprocessing" (number of Preprocessing Errors), and "Errors During Execution" (number of Execution Errors. Normal Web servers should not produce any errors. If errors occur in ASP. NET Web applications, their existence may lead to deviations in actual throughput results.
ASP. NET	Request Execution Time (Request Execution Time)		Displays the time (in milliseconds) required to render the requested page and send it to the user ). Tracking this counter is generally better than the display time of the tracking page. This counter can more comprehensively measure the entire request time from start to end. When compared with the benchmark, if the average value of this counter is low, the scalability and performance of the application are improved.
ASP. NET	Application Restarts (Application restart)		The number of times that an application restarts during the lifetime of the Web server. Each time an Application_OnEnd event occurs, the number of application restarts increases. The reason for restarting the application may be that the Web. the config File, changed the Assembly stored in the \ bin directory of the application, or made too many changes on the Web Forms page. An unexpected increase in the value of this counter indicates that some unpredictable problems have caused the Web application to be disabled. In this case, the cause of the problem should be carefully investigated.
ASP. NET	Requests Queued (number of Queued Requests)		The number of requests waiting for service in the queue. If this number grows linearly as the client load increases, it means that the Web server computer has reached the limit for concurrent requests that it can process. The default maximum value of this counter is 5,000. You can change this setting in the Machine. config file of your computer.
ASP. NET	Worker Process Restarts (the Worker Process Restarts)		The number of times a worker has restarted on a server computer. If an unexpected fault occurs or is intentionally recycled, the working process restarts. If the value of this counter increases unexpectedly, investigate the cause of the problem carefully.

ASP. NET Application performance counters

ASP. NET supports the following application performance counters, which can be used to monitor the performance of a single ASP. NET application instance. Each of these counters has a unique instance _ Total __. this instance aggregates the counters of all applications on the Web server (similar to the Global counters described in Section 1 of this topic ). The _ Total _ instance is always available. When no application is available on the server, these counters are displayed as zero.

Counter	Description
Active Sessions)	The number of active sessions. This counter reflects the total number of browser sessions that have not expired. This is not the number of requests simultaneously processed, but the number of sessions stored in the ReportServerTempDB database.
Cache Hits/Sec (Cache Hits per second)	The number of report requests obtained from the directory per second. If the value increases, but the value of "Memory Cache Hits" does not increase, the report data is not reprocessed, but the page is re-rendered. Use this counter with the Memory Cache Hits/Sec counter to determine whether there are sufficient resources for caching, disks, or Memory.
Cache Misses/Sec (Cache hits per second)	The number of requests that fail to be returned from the directory (relative to the memory) per second. This counter is used with the Memory Cache Misses/Sec counter to determine whether the resources used for caching, disks, or Memory are sufficient.
First Session Requests/Sec (number of First Session Requests per second)	The number of new user sessions started from the Report Server cache per second.
Memory Cache Hits/Sec (Memory Cache Hits per second)	The number of times reports are obtained from the cache in the memory per second. The in-memory cache is part of the Reporting Services cache and is used to save the reports that have been presented in the memory or temporary files. This can provide the best performance for requests, because no processing is required. If the cache is used in the memory, the reporting Server does not query the SQL Server to obtain the cached content.
Memory Cache Misses/Sec (Memory Cache hits per second)	The number of times the report is not obtained from the cache in the memory per second.
Next Session Requests/Sec (Next Session request per second)	The number of times a report is opened in an existing session per second.
Report Requests (Report request)	The number of reports that are currently active and will be processed by the Report Server.
Reports Executed/Sec (number of Reports Executed per second)	Number of successfully executed reports per second. This counter provides statistics on the amount of report processing. This counter is used in combination with Request/Sec to compare the execution status of the report Request returned from the cache.
Requests/Sec (number of Requests per second)	The number of requests sent to the Report Server per second. This counter tracks all types of requests processed by the Report Server.
Total Cache Hits (Total Cache Hits)	The total number of requests reported from the cache since the service was started. This counter is reset after ASP. NET stops the Web service.
Total Cache Misses (Total Cache miss count)	The total number of reports that cannot be obtained from the cache since the service is started. This counter is reset after ASP. NET stops the Web service. You can use this counter to determine whether the disk space and memory are sufficient.
Total Memory Cache Hits (Total Memory Cache Hits)	The total number of cached reports returned from the memory cache since the service is started. This counter is reset after ASP. NET stops the Web service. The cache in the memory is the part of the cache that stores the report in the CPU memory. If the cache is used in the memory, the reporting Server does not query the SQL Server to obtain the cached content.
Total Memory Cache Misses (Total Cache miss count)	The total number of cache hits in the memory since the service was started. This counter is reset after ASP. NET stops the Web service.
Total Processing Failures (Total number of Failures handled)	Total number of failures reported since the service was started. This counter is reset after ASP. NET stops the Web service. Troubleshooting may come from the reporting processor or any extensions.
Total Reports Executed (Total number of Executed Reports)	Total number of reports successfully executed since the service was started.
Total Requests (Total number of Requests)	Total number of requests sent to the Report Server since the service was started.