LR general performance analysis process

Step 1: analyze the transaction execution of summary
Summary mainly determines whether the transaction response time and execution conditions are reasonable. If any problem is found, further score is required.
Analysis. In general, if the transaction execution fails or the response time is too long, you need to perform in-depth analysis.
The following are some principles for viewing the analysis summary:
(1): whether all users are running, and whether maximum running vusers is consistent with the maximum number of concurrent users designed in the scenario. If no, you need to open the analysis diagram related to the virtual user to further analyze the Detailed causes of the virtual user's abnormal operation;
(2): whether the average response time of the transaction and the maximum response time of 90% transactions are acceptable to the user. If the transaction response time is too long
Long, you need to open various transaction-related analysis charts, in-depth analysis of the transaction execution;
(3): Check whether all transactions pass. If a transaction fails, you need to analyze the cause in depth. In many cases, failure to execute a transaction means that the system has encountered a bottleneck;
(4): if everything is normal, there is no need to conduct in-depth analysis in this test and stress testing can be performed;
(5): If the transaction fails too much, the stress should be reduced to continue the test, making the result analysis easier;
......
The above principles are some common methods for analyzing summary. They should be used flexibly and constantly summarized and improved, especially in combination with the actual situation.

Step 2: view the system resources of the load generator and server.
After viewing the analysis summary, you can view the system resource usage of the Server Load balancer instance to be tested: Check the CPU utilization and memory usage, and check whether there is a memory leakage problem. In this way, the bottleneck of the system is usually caused by high CPU utilization or insufficient memory.
Ensure that the CPU, memory, and bandwidth of the Server Load balancer have no Bottlenecks throughout the test; otherwise, the test result is invalid.
The server to be tested focuses on analyzing whether there is a bottleneck in the CPU memory during the testing process: the CPU needs to check whether the utilization rate often reaches 100% or the average utilization rate remains above 95%; check whether the memory is sufficient and whether there is overflow in the test process (for some middleware servers, check whether the allocated memory is sufficient ).

Step 3: view the detailed execution of virtual users and transactions.
After confirming that the execution of the test scenario is normal in the first two steps, check the execution of virtual users and transactions.
Status. For virtual users, check whether the test process is normal. If many users cannot run normally, re-design the scenario or adjust the user loading and exit mode to perform the test again. For transactions, focus on whether the transaction response time of the entire process is getting longer and whether there are transactions that cannot be normally executed.
In short, the execution details of each user or transaction should be carefully analyzed and cannot be easily ignored;
Example1: For a server with a gradual decline in performance, you need to further analyze the causes of the decline. [check whether there is a memory leakage problem ];
Example2: a relatively stable server, but the response time is too large. In this case, you need to analyze whether the program algorithm has defects or whether the server parameter configuration is reasonable.

Setp4: Check the error.
Errors During the entire test process should also be the focus of analysis. The following are common guidelines for viewing errors:
(1) check whether the error curve changes regularly throughout the test. If there is a regular pattern, it usually means that the program has some defects in concurrent processing. The number of defects per second curve shown in Figure 5-9 is quite regular. This is because the server regularly generates cached files and the user cannot access them normally. (Figure 0001)

(2) view error classification statistics as a reference for optimizing the system. For example, for Web performance testing, when a bottleneck occurs, you often need to view the server error statistics: if the "timeout error" accounts for more than 90%, you may need to improve the hardware configuration; if there are many "Internal Server errors", there may be program problems.
Step 5: view web resources and subdivided web pages.

This step is only applicable to Web performance testing. When viewing the Web Resource diagram, the analysis results of the previous virtual user and Transaction Response time are often combined to analyze the server stability. The following principles apply to the page subdivision function: First, analyze the steps that are time consuming from sending a request to receiving the first buffer; secondly, find out which components of the page have a great impact on the user response time. After locating the page performance problems, you can adopt related solutions.

LR general performance analysis process