My Architecture Experience series-backend architecture-performance level

Performance Level:

• Performance Analysis

I think we should pay attention to the following points for performance analysis:

1. Don't guess: Do you know how long your code will be executed for the code you write? Are you still using time subtraction to test the code execution time? There are many automated tools to test the execution time of each statement in the code when the program is running, which can effectively analyze the performance bottleneck of the Code. We recommend that you use similar tools for Performance Analysis for important business logic. Sometimes code with slow performance may not be written by yourself or provided within the framework, without a rich coding experience, it is not likely to know these points, but with such an analysis tool, you can know that this place will be slow, although we cannot change the Framework Code, however, we can cache or write data in another way. For example, you may think that obtaining the name of the current machine is a very fast operation. However, if it takes 5 ms to access the operation through certain operating system interfaces in the framework, it will be exaggerated, it is very likely that this operation has been run for 10 times in your entire request to obtain 10 machine names, so it will take up to 50 milliseconds without knowing it. At this time, you thought it was a slow database, this will never find the problem (the solution is relatively simple as long as the machine name is cached ). Therefore, in addition to adding some points to measure the code performance, it is more scientific to use some tools for measurement. Perhaps this tool itself is achieved by inserting countless points of code, but this is always better than Manually changing the code again and again. All in all, there are some performance problems not caused by your own code writing, external code or code in the framework, which cannot be guessed. Best Choice for Web Front-end framework!
2. Note the priority: Generally, we can think that the hardware is composed of CPU, memory, and Io, where I/O is divided into network and disk, whether it is the network or the disk, the performance is the worst and most likely to reach the performance bottleneck in the system. Knowing this, we know the performance analysis priority, ignoring database-level and network-level problems, wasting time and struggling with the performance of for/foreach, a pure language-level thing, is not that effective. Here are a few examples of typical immediate performance-related examples. It can also reflect how effective it is to see the problem through some means rather than simply guessing:

• • I have encountered an optimistic concurrency mechanism when using Orm, and passed the values of all fields as the where condition, there is a table with nearly fields, of course, the update efficiency is low, you can find out this problem by viewing the SQL statements that volume to the database, the solution is not to include related fields in the check or adopt pessimistic concurrency.
  • When using the memcached client, the factory object that should be used as a static Singleton is not used as a Singleton, but is created every time it is used. As a result, it takes 2 seconds to create a connection pool each time, the performance is extremely low, and tens of thousands of network ports are occupied. You can check the disk network parameters through basic operating system commands. The solution is to take the factory Singleton.
  • Once a program runs for only a few hours, it will occupy 10 Gb of memory and cause a crash. The Code cannot identify the problem. The problem can be identified shortly after the performance monitoring tool detects the virtual machine, the solution is to fix this bug.
  • The template used by a website is obtained from the network each time. As a result, each request is sent to the server again to download the page from other websites and then process it, the performance is extremely low. The second concurrency can only be around 10. It is not difficult to identify this problem. It takes 1 second to cache the template.

3. note: For many components (such as MongoDB), Basic System configurations are checked during initialization. If a component cannot reach the optimal value due to improper configuration, a prompt is displayed, therefore, pay attention to the logs of these components to detect performance problems as soon as possible. Best Choice for Web Front-end framework!

 

• Stress Testing

Although some tools can help us analyze program performance, some performance problems must be produced under high pressure. A typical lock is used for thread security. Whether it is a program-Level Lock or a database-Level Table lock row lock, the lock means serial, serial means that the larger the pressure, the slower the queue. Of course, stress testing may also test the thread security problems caused by the multi-threaded environment. The overall performance of the system is dragged down by the worst point. If there is a large gap in the compression capacity of each module of the system, stress testing is easier to detect problems. As a website developer, we should be conscious about how many requests can be processed per second for common servers, and how many operations can be processed by databases per second, if you find that after stress testing, the web server can only process up to 10 concurrent requests per second, the system must have performance problems. Stress testing can not only test system problems, but also test the maximum number of visitors allowed by the system under certain hardware conditions, which is lower than the minimum number of visitors, the response of the system exceeds this number is declining. Based on this result, we can reasonably select the number of clusters.

 

• Online troubleshooting

Performance analysis tools are unlikely to run online code because the code executed using these tools is several times slower than running Code directly, if you do this online, your website may crash. Best Choice for Web Front-end framework!

1. A simple method is to add some points and deploy the code grayscale to some machines to view logs to analyze the cause.
2. Alternatively, you can capture process samples on a machine for static analysis (especially suitable for languages with virtual machines ). By capturing a sample of a process, you can find out which objects in the process occupy most of the memory, and analyze the memory performance problems by garbage collection in the status of each zone. By capturing samples of multiple processes, you can compare the threads that consume a lot of time and the threads that consume a lot of time. multithreading mainly focuses on the code to analyze CPU performance problems.
3. In addition to this internal analysis method, you can also analyze it externally. For example, you can use tools such as fiddler to check whether the slow speed is due to network or concurrency or the server. For example, you can use a database monitoring tool to monitor the execution time of each SQL statement to capture the slowest SQL statement. For example, by observing the status of the virtual machine, observing the performance indicators of the operating system, and observing the performance counters of windows, you can help determine the approximate existence of performance problems.

My Architecture Experience series-backend architecture-performance level