Shulou(Shulou.com)06/03 Report--

This article shares some of the challenges of implementing an effective APM strategy. Xiaobian thinks it is quite practical, so share it with everyone for reference. Let's follow Xiaobian and have a look.

1. Code dependency

Developing programs is challenging work. Not only do you have to build the logic to meet your business needs, but you also have to choose the most appropriate code base and tools to help you. Can you imagine creating all the log management code, XML and JSON parsing logic, or all the serialization libraries? You can write code to do all of these things, but there are teams of open source developers who already do all of these things, so why do you have to do it yourself? Also, if you are integrating with third-party systems, would you read proprietary communication protocol specifications yourself, or would you buy a vendor library to do it for you?

I'm sure you'll agree that if someone has solved your problem, it's more efficient to use their solution than to figure it out yourself. If this is an open source project that has been adopted by many companies, it is likely to be well tested, well documented, and you should find plenty of tutorials.

However, using dependency libraries is dangerous. You need to answer the following questions:

Is this library really well written and fully tested?

Do you use this library in the same way as many companies do?

Are you using it correctly?

Be sure to do some research before choosing an external library, and if you have questions about the performance of a library, do some performance testing. The great thing about open source projects is that you can access their entire source code as well as test suites and build processes. Download their source code, perform the compilation process, and view the test results. If you see high test coverage, you can be more confident than if you had no test cases!

Finally, make sure the dependency library is used correctly. When 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 them correctly, you can easily smash your feet and ruin your app's performance. The point is that if you don't take the time to learn these tools, the tools that are supposed to help you will hurt you instead.

Excessive or unnecessary logging

Logging is a powerful tool in the debugging toolkit that can help you identify exceptions that may occur at certain times during application execution. When errors occur, it is important to capture error information and gather as much context as possible. However, there is a difference between concisely capturing error conditions and over-recording them.

The two most common problems are:

Multi-level exception log

Production log level incorrectly configured

Exception logging is important because it helps you understand what is happening in your application. But a common problem is that exceptions are logged at all levels of the application. For example, one of your data access objects catches 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 log the exception at the data layer, service layer, and network layer, we have three stack records for the same error condition. This results in an additional burden of writing to the log file and also fills the log file with redundant information. But the problem is so common that I dare assert that if you examine your log files, you will likely find multiple examples of it.

Another big logging problem common in production apps has to do with logging levels. The. NET logger defines the following logging levels (. NET TraceLevel is named differently than log4net, but is absolutely similar):

Off

Fatal

Error

Warning

Info

Verbose / Debug

In a production application, you should only log statements at the error or metal level. In a more relaxed environment, it's fine to capture warning or even info logs, but once the application goes into production, the user load will quickly fill the logs and crash the application. If you inadvertently set the app log level to debug in a production environment, it's not surprising that your app's response time is two or three times higher than normal!

3, synchronization and lock

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

No matter why you synchronize your code or what mechanism you choose to synchronize your code, it leads to a problem: parts of your code can only be executed by one thread at a time. Imagine going to a supermarket and having only one cashier at work: many people enter the store, browse through items, and put items in shopping carts, but at some point they have to queue up to pay. In this example, shopping is multithreaded, and each person represents a thread. Checkout, however, is single-threaded, which means everyone spends time queuing up to pay. This process is illustrated in Figure 1.

Figure 1: Thread synchronization

We have seven threads that all need access to a synchronized block of code, so they in turn gain access to that block, perform its function, and then move on.

The thread synchronization process is summarized in Figure 2.

Figure 2 Thread synchronization process

First, a lock is created for a particular object (derived from System.Object), meaning that a thread must acquire a lock on that synchronized object when it attempts to enter a synchronized block of code. If the lock is available, the thread is granted permission to execute synchronized code. In the example in Figure 2, when the second thread arrives, the first thread already owns the lock, so the second thread is forced to wait until the first thread finishes executing. When the first thread finishes executing, the lock is released, and the second thread is granted access.

As you might guess, thread synchronization presents a major challenge for. NET applications. We design our applications to support dozens or even hundreds of simultaneous requests, but thread synchronization serializes all threads processing those requests, leading to performance bottlenecks!

There are two solutions:

Examine synchronized code carefully to see if there are alternatives

Limit the range of sync code blocks

Sometimes you have access to shared resources that must be synchronized, but many times you can resolve the problem by avoiding synchronization altogether. For example, the rule process engine we used earlier had a single-threaded requirement, which slowed down the execution of all requests in the program. This is obviously a design flaw, and we can replace it with a library that works 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 that stores it in a database? Can you make an object immutable so that it doesn't matter whether there are multiple threads accessing it? Wait, wait, wait...

For code snippets that must be synchronized, choose locks wisely. Your goal is to isolate blocks of synchronized code to meet minimal synchronization requirements. It is often better to define a specific object to synchronize than to synchronize an object that contains synchronization code, because you may inadvertently slow down other interactions with that object. Finally, consider using read/write locks instead of standard locks so that you can allow reads when resources are only changing synchronously.

4. Potential database issues

Almost all content applications eventually involve storing/retrieving data to/from a database or document store. Therefore, database, database queries, and stored procedure tuning are of paramount importance to application performance.

There is a philosophical division between program architects/developers and database architects/developers. Application architects tend to think that all business logic should reside in the application and that the database should only provide access to the data. Database architects, on the other hand, tend to think that pushing business logic into the database is more beneficial for performance. The answer to this division is probably somewhere in between.

As an application architect, I tend to apply more business logic to my applications, but I fully recognize that database architects are better able to understand data and the best way to interact with it. I believe that synergy between these two groups produces the best solutions. However, no matter which side you prefer, make sure your database architect reviews your data model, all query statements and stored procedures, they have extensive knowledge to help you tune and configure your database in the best way, and they have a number of tools to tune query statements for you. For example, there are tools available for SQL tuning, follow these steps:

Parsing SQL statements

Determine the execution plan for the query

Using artificial intelligence to generate alternative SQL statements

Identify implementation plans for all options

Propose the best query method to achieve the goal

When I was writing database query code, I used these tools and quantified the results under heavy load, with minor tweaks and optimizations that could lead to significant performance improvements.

Potential infrastructure issues

As mentioned earlier,. NET applications run in a hierarchical environment, with the hierarchy shown in Figure 3:

Figure 3.NET layered execution model

Your application runs in ASP.NET or Windows Forms containers and uses ADO libraries to interact with databases running inside the CLR, which runs in the operating system, which runs in hardware. This hardware, in turn, is networked to other hardware containing different technology stacks. There are often multiple load balancers between your application and the external environment, as well as between components of your application. We also have API management services and multi-level caching. All of this to illustrate that a large number of infrastructure can affect application performance!

So you have to fine-tune your infrastructure. Check the operating systems and hardware devices on which your application components and databases are running to ensure they perform optimally. Measure network latency between servers and make sure you have enough bandwidth to accommodate interactions between applications. Check the cache to ensure a high cache hit rate. Analyze load balancer behavior to ensure requests are distributed quickly to all available servers. In summary, you need to thoroughly examine the performance of your applications, both in terms of application business transactions and the infrastructure that supports them.

Thank you for reading! About "What are the challenges facing the implementation of effective APM strategy" this article is shared here, I hope the above content can be of some help to everyone, so that everyone can learn more knowledge, if you think the article is good, you can share it to let more people see it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.