Not to be overlooked. NET Application 5 Big Performance problems _ Practical Tips

The challenges of implementing an effective APM strategy:

• Code dependencies
• Excessive or unnecessary log
• Sync and lock
• Potential database problems
• Potential infrastructure issues

1. Code dependence

The development process is a challenging task. Not only do you have to create program logic to meet business needs, but you also need to choose the most appropriate code base and tools to help you. Can you imagine yourself creating all the log Management code, XML and JSON parsing logic, or all of the serialization libraries? You can certainly write code to do these things, but the many open source developer teams are already doing these things, so why do you have to be so pro? In addition, if you are integrating with a third-party system, will you read the proprietary communication protocol specification yourself, or do you buy a vendor-provided library to help you complete it?

I'm sure you'll agree: If someone has solved your problem, using his solution will be more efficient than finding a way to solve it. If this is an open source project that has been adopted by many companies, it is likely that it has been fully tested, well documented, and that you should find a lot of tutorials to use.

However, the use of dependent libraries is risky. You need to answer the following questions:

• Is the library really well written and fully tested?
• Do you use this library in the same way as many companies do?
• Are you using the right way?

Be sure to do some research before selecting an external library, and if you have any questions about the performance of a library, perform some performance testing. The good thing about open source projects is that you can access all of their source code and test suite and build process. Download their source code, perform the compilation process, and view the test results. If you see very high test coverage, then you can be more confident than no test case!

Finally, make sure that the dependent libraries are used correctly. If used correctly, ORM tools can really improve performance. The problem with ORM tools is that if you don't take the time to learn how to use it correctly, you'll easily hit your own feet and ruin your application performance. The key is that if you don't take the time to learn these tools, the tools that should help you will hurt you.

2, excessive or unnecessary log

Logging is a powerful weapon in the Debug ToolPak that can help you identify the exceptions that may occur during a specific period of time during application execution. When an error occurs, it is important to catch the error message and collect as many contextual information as possible. However, there is a difference between simply capturing the error condition and the excessive record.

The two most common problems are:

• Multi-level Exception Log
• Error configuring production log level

The Exception Log can help you understand the problems that occur in your application and is therefore very important. A common problem, however, is that all levels of the application's exceptions are logged. For example, one of your data access objects captures a database exception and communicates the exception to the service layer. The service layer may catch the exception and communicate it to the network layer. If we record the exception on the data tier, the service layer, and the network layer, then we have three stack records for the same error condition. This causes an additional burden to write to the log file, and also makes the log file full of redundant information. But this is a very common issue, and I'm pretty sure that if you check your own log files, you'll probably find multiple examples.

Another large log problem that is common in production applications is related to the log level. The. NET logger defines the following logging levels (the names in. NET TraceLevel and log4net differ, but are absolutely similar):

• Off
• Fatal
• Error
• Warning
• Info
• Verbose/debug

In a production application, you should only record error or fetal-level log statements, and in a more relaxed environment, capturing warning and even info-level log information is perfectly OK, but once the application is put into production, the user load will quickly fill the log and paralyze the application. If you inadvertently set the application log level in the production environment to debug, it is not surprising that the application response time is two or three times times higher than normal!

3, synchronization and lock

Sometimes you want to make sure that only one thread in the application code executes a subset of the code at a time. For example, you read shared software resources, such as a single-threaded rule execution component, and shared infrastructure resources such as file handles or network connections. The. NET Framework provides a number of different types of synchronization strategies, including lock/monitor, inter-process mutex, and read/write locks.

No matter why you sync the code or what mechanism you choose to implement the code synchronization, there is a problem: there is some code that can only be executed by one thread at a time. Imagine going to the supermarket, where only one cashier is working: Many people go into stores, browse goods, and put goods into their shopping carts, but at some point they have to queue up to pay. In this example, shopping is multithreaded, and everyone represents a thread. However, the checkout is single-threaded, which means that everyone has to spend the time in the queue for payment. This process is shown in Figure 1.

Figure 1: Thread synchronization

We have seven threads that need access to a block of synchronized code, so they get permission to access the code block sequentially, perform its function, and then continue.

The process of thread synchronization is summarized in Figure 2.  

Figure 2 Thread synchronization process

First, creating a lock for a particular object (System.Object) means that when a thread attempts to enter a synchronized code block, it must obtain the lock of the synchronization object. If the lock is available, the thread is granted permission to execute the synchronization code. In the example in Figure 2, when the second thread arrives, the first thread already occupies the lock, so the second thread is forced to wait until the first thread completes. When the first thread finishes executing, the lock is released, and the second thread is granted access.

As you may have guessed, thread synchronization poses a great challenge to. NET applications. When we design an application, we want it to support dozens of or even hundreds of simultaneous requests, but thread synchronization will serialize all the threads that handle those requests, leading to performance bottlenecks!

There are two ways to solve this problem:

• Carefully examine the synchronized code to determine if there are other possible alternatives
• Limit the scope of a synchronized code block

Sometimes you have to access shared resources that must be synchronized, but many times you can solve the problem in a way that avoids synchronization altogether. For example, the rule process engine that we used earlier has a single-threaded requirement, thus slowing down the execution speed of all requests in the program. This is obviously a design flaw and we can replace it with a library that can work in parallel. You need to ask yourself if you have a better choice: if you are writing to a local file system, can you send the information to a service and then store the information in the database? Can you make the object immutable so that it doesn't matter if you have multiple threads accessing it? Wait, wait...

For those sections of code that must be synchronized, choose a lock reasonably. Your goal is to isolate the synchronized blocks of code to meet minimum synchronization requirements. It is usually best to define a particular object for synchronization, rather than synchronizing the object that contains the synchronization code, because you may inadvertently slow down other interactions of that object. Finally, consider using read/write locks, rather than standard locks, so that you can allow read operations when resources are only synchronized.

4. Potential database problems

Almost all content applications will ultimately involve storing/retrieving data to/from a database or document store. Therefore, database, database query, and stored procedure tuning are most important to the performance of your application.

There is a philosophical division between the program architect/developer and the database architect/developer. Application architects tend to assume that all business logic should reside in the application, and that the database should provide only the channel to access the data. Database architects, on the other hand, are more inclined to think that pushing business logic into the database is more beneficial to improve performance. The answer to this division is likely to be somewhere between the two.

As an application architect, I tend to apply more business logic to the program, but I fully recognize that the database architect can better understand the best way to interact with data and data. I believe that the synergy between the two groups can produce the best solution. However, regardless of which side you prefer, make sure your database architect checks your data model, all the query statements and stored procedures, and they have a wealth of knowledge to help you tune and configure the database in the best way, and they have a lot of tools to adjust the query for you. For example, there are a number of tools available for SQL tuning, following these steps:

• Parsing SQL Statements
• Determine the execution plan for a query
• Using artificial intelligence to generate alternative SQL statements
• Determine the plan of implementation for all options
• Propose the best way to achieve the goal

When I write the database query code, I use this kind of tools, and in the high load situation to quantify the results, some minor adjustments and optimizations, can lead to a great performance improvement.

5. Underlying infrastructure issues

As mentioned earlier,. NET applications run in a layered environment, and the hierarchy is shown in Figure 3:

Figure 3. NET layered Execution Model

Your application runs in asp.net or Windows Forms containers, using the ADO library to interact with databases running inside the CLR, while the CLR is running in the operating system and the operating system is running in hardware. The hardware is also connected to other hardware that contains different technology stacks over the network. There are usually multiple load balancers between your application and the external environment, as well as between the applied components. We also have API management services and multilevel caching. All of this is to illustrate the complexity of the infrastructure that can affect application performance!

so you have to fine-tune the infrastructure. Check the operating system and hardware devices that your application components and databases run to ensure their best performance. Measure network latency between servers and ensure that you have enough bandwidth to accommodate the interaction between applications. Check the cache to ensure a higher cache hit rate. Analyze the behavior of the load balancer to ensure that requests are quickly distributed to all available servers. In short, you need to fully review the performance of your application, including both the application business transactions and the infrastructure that supports them.