Getting Started with ASP.NET Performance Monitoring and Optimization

Key points:

• Infrastructure metrics are most effective only when linked to application metrics.

• 
  

• The key to efficient performance optimization lies in performance data.

• 
  

• Some APM tools provide out-of-the-box support for ASP.NET, so getting started with ASP.NET requires minimal initial setup.

• 
  

• Code analysis tools give the most detailed view of program performance.

• 
  

• The lightweight analysis tool gives a real-time view of web page performance and can be used in both development and production environments.

"This web page opens too slowly!" This complaint about Web sites is frequent and common, especially since Web applications began to gradually replace desktop applications. Although the Web brings ideal features such as global delivery, it also brings corresponding challenges at the performance level.

Basic principles of data collection and use

The user gave you the URL of a "slow" web page, so what should you do? Where does the problem of slow web page opening come from? Was it so slow from the beginning? Is it slow for all users? There are many issues like these that need to be addressed to resolve the problem of slow web pages opening and ensure that they don't slow down again after a week.

Although you can search for some performance optimization information on the Internet, they are usually about specific topics such as Jit, garbage collection, SQL query optimization, ORM traps, etc. Given the enticing prospect of implementing optimizations, a question arises: How do you know that the chosen optimization method will actually produce good results for your current performance problem?

There is no doubt that something is missing in this work. We need ways to find performance problems sustainably. By using this approach, we can identify slower parts of the system and have tangible measures to support our diagnosis of performance issues. Once we understand where the performance issues lie, we can further determine whether performance improvements are needed and explain all of this to stakeholders.

For the above-mentioned performance problems found, accurate identification is a more effective way to deal with them. The problem may not be a slow loading of the web page in the first place. In the presence of timeouts (for example, the load balancer may wait several seconds before servicing the connection), it is impossible to tell whether this is a deadlock problem or a slow response time problem, because both problems cause the same The result is a timeout. This requires data to find the real cause of the problem.

To illustrate the importance of accurately identifying performance issues, here are some possible troubleshooting points that cause slow response in web applications:

• JavaScript responds slowly;

• 
  

• Blocking occurs during resource loading;

• 
  

• There is a proxy on the client side;

• 
  

• DNS problem;

• 
  

• ISP or network problem;

• 
  

• Switches and routers;

• 
  

• Load balancer;

• 
  

• Application code (including third-party software libraries);

• 
  

• HTTP server (e.g. sometimes ASP.net or IIS);

• 
  

• Third-party services, such as: payment service providers, map service providers, etc.;

• 
  

• Subsystems, including: SQL Server, Redis, Elasticsearch, Rabbit MQ, etc.

Additional performance troubleshooting points can be listed, depending on the complexity and size of the system to be addressed. How can you diagnose performance issues when so many system components can affect performance optimization issues? The answer can be summed up in one word: data. You need relevant and meaningful data from every system component. For the problem of slow web application response, data can prove whether each system component has an impact on the problem or is completely irrelevant.

With the data in hand, you can start to extract troubleshooting points from the above list according to your ideas for analysis, which is similar to searching in a sorting tree. Each time you go down one level in the tree, you get closer to the details and essence of the performance problem, and identify whether the performance problem exists in:

• Client side, server side or somewhere in between?

• 
  

• Slow JavaScript, rendering, or resource blocking?

• 
  

• Load balancer, web server, any subsystem or third-party software?

As you go down level by level in such a tree, performance issues become increasingly clear. For each level of troubleshooting, the data required to locate performance issues must match the accuracy of the corresponding problem. At this time it is necessary to use tools such as performance analysis tools or SQL execution plans.

In order to use time effectively, it is necessary to reiterate Amdahl's law:

No matter how much a task is improved, the parts of the task that do not benefit from the improvement limit theoretical task speedup.

For example, in a web request, it is assumed that 100 milliseconds of server processing time and 5 seconds of SQL query time are required. Even if you can optimize the server processing time to less than 1 millisecond, the improvement in overall response time is small, from 5.1 seconds to 5 seconds. The 5 seconds required to improve SQL processing is the optimization with the greatest potential gain.

Architectural issues

This top-down method of clarifying optimization problems layer by layer has a good effect on optimization problems limited to a single page. So what is the effect when applied to optimization problems that span multiple pages? For example, the problem of intermittently slow opening of some pages is due to the subsystem not being able to keep up with the overall work rhythm, or due to the presence of an old network switch in the system that may no longer work after restarting.

In this case, the application-focused monitoring approach shows its limitations. This requires more software-level and hardware-level metrics to evaluate each component in the system.

At the hardware level, the first things that come to mind are web servers and database servers, but they are just the tip of the iceberg. Hardware components in all systems must be identified and monitored. This includes: servers, network switches, routers, load balancers, firewalls, SANs, etc.

Given that the system administrator’s regular job is hardware monitoring, all of the above indicators may be obvious to the system administrator. But here's an important caveat: most of all these hardware metrics are useless from a performance perspective if they are treated separately from software metrics. In other words, indicators can only work best if they are placed in the appropriate environment.

For example, in some cases it may be perfectly normal for the CPU usage to average 50% on a database server, but for other servers this is a ticking time bomb. 50% CPU usage, if it is at peak times, means there is still a lot of room to run more heavy tasks. But if 50% CPU usage occurs frequently during idle periods, this means that the application may not be able to withstand sudden spikes in incoming requests.

The bottom line is that to assess system health, system-wide metrics such as CPU, memory, and disk must be correlated with application metrics. To give a more complete view of system health, application metrics such as request throughput and system metrics such as CPU utilization can be visualized.

Application Performance Management (APM) tool

APM tools provide basic operations such as data collection, data storage and data visualization. Typically an agent is responsible for collecting and sending data to a data store, and using a web interface to visualize the data in a dashboard focused on web requests.

​APM can be used for:

• Provide overall visualization of Web application performance;

• 
  

• Visualize specific web request performance;

• 
  

• Automatically send alerts when web application performance deteriorates or multiple errors occur;

• 
  

• When the business volume is large, verify the response mode of the application.

Examples are given here.

The following is a non-exhaustive list of APM tools that support ASP.NET and IIS out of the box:

• NewRelic APM

• 
  

• Application Insights

• 
  

• AppDynamics

• 
  

• Stackify

Infrastructure monitoring tools

Infrastructure monitoring tools collect metrics at the host level, which can more completely reflect performance. These metrics are collected at the hardware and software levels.

• DataDog

• 
  

• OpServer - Open Source

Lightweight analysis tool

Lightweight analysis tools provide high-level metrics for specific web requests and provide real-time feedback as developers browse web pages. These tools can be used in all environment types (including development environments, QA verification, staging environments, production environments, etc.), so they are ideal for quick assessment of specific page performance.

Compared with the corresponding full-featured analysis tools, the essential difference between lightweight analysis tools is that they are not attached to the process, which means that you do not need to worry about the overhead they generate when using lightweight analysis tools.

In the development environment, lightweight analysis tools provide real-time feedback on the code currently being written. This is very useful for spotting issues like N+1 or slow response times, since response times are always displayed in the corner of the page.

• Open source MiniProfiler

• 
  

• Open source Glimpse

Fill in the gaps with performance counters

Performance counters in Windows systems provide different indicators at the hardware and software levels. Monitoring tools often report performance counters, such as CPU and memory usage. But often some useful counters are missing, such as garbage collection time, etc. The most practical way to get started is to use a basic list and add the necessary relevant counters to the iteration. In addition, it is possible to use perfmon to collect and visualize performance counters in real time. In many cases, it is also feasible to integrate user-customized indicators or plug-ins with APM tools.

SQL Tool

Since databases are commonly used in many applications, the persistence layer (i.e. SQL database) often becomes a performance bottleneck. Professional tools for SQL monitoring can provide resource usage metrics, as well as specific metrics such as wait times, compiles per second, etc., to name just a few.

By providing the following data, some types of problems can be discovered and performance can be improved:

• Excessive throughput on one or several queries;

• 
  

• Excessive CPU usage, which suggests query problems or missing indexes;

• 
  

• High-throughput queries that can be cached.

SQL monitoring tools include:

• RedGate SQL Monitor

• 
  

• SQLSentry Performance Advisor

Other persistence systems

All subsystems need to be monitored to some extent. For low-throughput or non-critical systems, simple data collection and visualization will suffice. In other cases, more advanced, professional monitoring is required.

Code analysis tool

When a particular page or piece of code has been identified as slow, code analysis tools can provide the most detailed view possible for performance issue identification. Code analysis tools also provide a precise view of external calls such as database queries and web requests.

analyzing tool:

• Redgate Ants

• 
  

• JetBrains dotTrace

Memory analysis tool

Memory monitoring and garbage collection metrics help detect potential problems. But while these indicators show that there is a problem, they often don’t tell where the problem is. If you need to dig deeper into memory and garbage collection issues, memory analysis tools can come in handy.

analyzing tool:

• JetBrains dotMemory

• 
  

• RedGate Ants Memory Profiler

Client analysis tool

Performance issues may also come from the front end. This problem is very common nowadays due to the proliferation of single-page applications powered by JavaScript. All major browsers have embedded tools such as code analysis and memory analysis. Tools that display the sequence of events and requests help determine at a glance whether a problem originates from the front end or the back end.

Tools:

• Google Chrome Timeline

• 
  

• Firefox

Page analysis tool

High-level client tools provide a convenient starting point for identifying and resolving performance issues. These tools can provide a high-level view of the root causes of response time problems and provide some corresponding recommendations. For example, Google's PageSpeed ​​Insights is such a free tool.

There are so many factors and tools related to system performance that it may seem complicated. But they can be summed up in one word: data. Having a clear and accurate view of the system makes it possible to reason about performance issues. This also allows you to learn how to troubleshoot performance issues on the spot, as performance metrics and graphs will guide you to discover what exactly is affecting system performance.

The above is the detailed content of Getting Started with ASP.NET Performance Monitoring and Optimization. For more information, please follow other related articles on the PHP Chinese website!