Recently, I have been struggling with how to start performance analysis and tuning, whether to start with the hardware or the code or database. Start with the operating system (CPU scheduling, memory management, process scheduling, disk I/O), network, protocol (HTTP, TCP/IP), or application code, database tuning, middleware configuration, etc.
A single middleware is divided into web middleware (apache, IIS), application middleware (tomcat, weblogic, webSphere), etc. Although they are all middleware, it will not be easy to learn each one in depth. But tuning requires more than just "knowing" or "being able to use" each item. At least to achieve "how to use it better".
It is often said in performance testing books that performance testing is not just a matter of performance testing engineers. It requires the cooperation of DBA, developers, and operation and maintenance personnel to complete. However, in many cases, performance testing is completed independently by performance testers. Even if it is assisted by other personnel, understanding the various modules of the system architecture will be of great help to one's own improvement, and it will also be easier to gain the support of others. respect.
Before we talk about performance tuning, we need to mention the purpose of testing again, or what is our original intention for performance testing?
Capability verification: Verify what capabilities a system has under certain conditions.
Capacity planning: How to make the system achieve the performance capabilities we require.
Application diagnostics: For example, memory leaks are difficult to find through functional testing, but easy to find through performance testing.
Performance tuning: Meet user needs, conduct further system analysis to identify bottlenecks, optimize bottlenecks, and improve overall system performance.
Generally, the bottleneck
performance testing and tuning of the system requires the bottleneck to be discovered first, so what bottlenecks generally exist in the system:
Performance bottlenecks on hardware:
Generally refers to issues related to CPU, memory, and disk I/O, which are divided into server hardware bottlenecks, network bottlenecks (the LAN does not need to be considered), server operating system bottlenecks (parameter configuration), and middleware bottlenecks (parameter configuration, database, web server, etc.), application bottlenecks (SQL statements, database design, business logic, algorithms, etc.).
Performance bottlenecks in application software:
Generally refers to application software such as application servers and web servers, as well as database systems.
For example: The parameter settings of the JDBC connection pool configured on the middleware weblogic platform are unreasonable, causing bottlenecks.
Performance bottlenecks on the application:
Generally refers to applications newly developed by developers.
For example, the program architecture planning is unreasonable, and there are problems with the design of the program itself (not enough threads for serial processing and request processing), resulting in bottlenecks caused by low performance of the system when a large number of users are located.
Performance bottlenecks on the operating system:
Generally refers to operating systems such as windows, UNIX, and Linux.
For example, during performance testing, when there is insufficient physical memory and the virtual memory settings are unreasonable, the exchange efficiency of virtual memory will be greatly reduced, resulting in a greatly increased response time of the behavior. At this time, it is considered that a performance bottleneck occurs on the operating system.
Performance bottlenecks on network equipment:
Generally refers to firewalls, dynamic load balancers, switches and other equipment.
For example, a dynamic load balancer is set up with a dynamic load distribution mechanism. When it is found that the hardware resources on an application server have reached the limit, the dynamic load balancer will send subsequent transaction requests to other lightly loaded application servers. . During the test, it was found that the dynamic load balancer did not play a corresponding role, which can be considered a network bottleneck.
The reasons for the emergence of performance testing and their positioning are very complex. Here is a brief introduction to several common bottleneck types and characteristics. What performance testing needs to do is to comprehensively consider various factors and then assist developers\DBA\operation and maintenance personnel. Locate performance bottlenecks together.
General performance tuning steps
Steps for general performance problem tuning:
Step 1: Determine the problem
Application code: Under normal circumstances, many program performance problems are written out, so for modules where bottlenecks are found, the code should be checked first.
Database configuration: often causes the entire system to run slowly. Some large databases such as Oracle require the DBA to make correct parameter adjustments before they can be put into production.
Operating system configuration: Unreasonable configuration may cause system bottlenecks.
Hardware settings: hard disk speed, memory size, etc. are all likely to cause bottlenecks, so these are the focus of analysis.
Network: Overloaded network causes network conflicts and network delays.
Step 2: Identify the problem
After identifying the problem, we need to clarify whether this problem affects response time throughput or other problems? Are most users or a few users experiencing problems? If there are a few users, what are the differences between the operations of these users and other users? Are the system resource monitoring results normal? Has CPU usage reached its limit? What's going on with I/O? Are the problems concentrated in a certain type of module? Is there a problem with the client or the server? Is the system hardware configuration sufficient? Does the actual load exceed the system's load capacity? Is the system not optimized?
Through these analyzes and some system-related issues, we can have a deeper understanding of system bottlenecks and then analyze the real causes.
Step 3: Determine adjustment goals and solutions
Improve system throughput, shorten response time, and better support concurrency.
Step Four: Test the Solution
Benchmark the solution-tuned system. (Benchmark testing refers to the quantitative and comparable testing of a certain performance indicator of a type of test object through the design of scientific testing methods, testing tools and testing systems)
Step 5: Analyze tuning results
Did system tuning meet or exceed predetermined goals? Has the overall performance of the system been improved, or is the performance of a certain part of the system used to solve other problems? Can tuning be completed?
Finally, if the expected goals are achieved, the tuning work is basically over.
The following is a technique. For example, if the interviewer asks a performance question and I don’t know where the performance problem lies, I can answer according to this idea ^_^
• When finding bottlenecks, proceed in the following order, from easier to more difficult.
Server hardware bottleneck ---〉Network bottleneck (for LAN, you can ignore it) ---〉Server operating system bottleneck (parameter configuration) ---〉Middleware bottleneck (parameter configuration, database, web server, etc.) ---〉 Application bottlenecks (SQL statements, database design, business logic, algorithms, etc.)
Note: The above process is not required in every analysis. The depth of analysis must be determined based on the test purpose and requirements. For those with low requirements, it is enough for us to analyze where the hardware bottlenecks of the system will be under the future heavy load pressure of the application system (number of concurrent users, amount of data).
• Segmented elimination is effective
Key points that should be paid attention to when tuning performance tests:
Point 1: In the design and development process of application systems, performance should always be taken into consideration.
Key Point 2: Setting clear and unambiguous performance goals is key.
Point 3: It is necessary to ensure that the tuned program runs correctly.
Point 4: The performance of the system depends more on good design, and tuning skills are only an auxiliary means.
Point 5: The tuning process is an iterative and gradual process, and the results of each tuning must be fed back to subsequent code development.
Point 6: Performance tuning cannot be done at the expense of code readability and maintainability.
This article only introduces some things to pay attention to in performance tuning and the general points of performance tuning. It does not specifically explain how to tune each component of the system. How to explain it in detail cannot be explained in one or two books. The knowledge requirements are also very high, which is beyond my current ability.
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
