1. Purpose of software performance test:

  • Evaluate the current system performance and determine whether the system meets the expected performance requirements
  • Identify performance problems that may exist in the software system, locate performance bottlenecks, and resolve the problems
  • Determine software system performance, anticipate system load, and evaluate system performance prior to application deployment

For users, the most concerned system:

  • Check whether the online performance requirements are met
  • What is the ultimate system load
  • How stable is the system

2. Key indicators in the software performance test

The resource indicator refers to the usage of server resources by application services, including CPU, memory, I/O, and broadband. System indicators refer to the specific performance of application services or application systems, such as the number of concurrent users, response time, transaction success rate, and timeout time



Resource indicator CPU usage: Indicates the percentage of CPU time consumed by user processes and system processes. In a long period of time, the upper limit is 85%. Memory usage LV = (1- Free memory/Total memory size) x 100%. Generally, at least 10% of the available memory is available, and the upper limit for memory usage is 85%. Disk I/O: Disks are used to read and write data. Data is read I/O operations. Generally, %Disk Time is used to measure Disk read/write performance. Network bandwidth: Bytes Total/ SEC is expressed as the rate at which Bytes are sent and received, including frame characters. To determine whether the network connection speed is a bottleneck, compare the value of this counter with the bandwidth of the current networkCopy the code

System specifications Number of concurrent users: the number of users who submit requests to the system at the same time at a certain physical time Number of online users: the number of users who access the system at a certain time but do not submit requests at the same time Average response time: the average response time of the system processing transactions. The response time of a transaction is the time between the client submitting the access request and the client receiving the server response. For system rapid response page, average response time is about 3 s transaction success rate: performance tests, define transaction is used to measure one or more business process performance metrics, such as user login, save the order, submit orders can be defined as transaction operation Timeout error: refers to a transaction failed due to timeout or other errors within the system the ratio of total transactionCopy the code

3. Troubleshooting of performance problems

During performance testing, if performance problems occur, testers should focus on resource indicators, system indicators or application performance data. System indicators are directly observed test data, such as long response time, low success rate of transaction requests, high timeout error rate, and so on. Resource indicators, such as high CPU usage, high memory usage, high network bandwidth usage, and high number of connections, may cause problems in system indicators.
When system resource anomalies are observed, such as long response time, low transaction success rate, and high timeout error rate. Check application information, such as logs, application monitoring, and database information. If the information is correct, then analyze the resource information. The resource information is analyzed as follows.
CPU problem analysis: In general, the CPU is working at full load. Sometimes, it cannot be judged as a CPU bottleneck. For example, Linux always tries to keep the CPU as busy as possible to maximize the throughput of tasks, that is, the MAXIMUM CPU usage. Therefore, CPU is generally judged as the bottleneck, mainly from two aspects: The bottleneck can be determined if the CPU idle duration is 0 or the run queue is larger than the number of CPU cores (3-4 times the empirical value). The main cause of high CPU consumption may be unreasonable application programs or insufficient hardware resources, which needs to be analyzed in detail, such as SQL statements. You need to track and tune SQL statements that cause CPU overuse.
Memory problem analysis: Generally, at least 10% memory is available, and the upper limit for memory usage is 85%. When the free memory becomes small, the system frequently transfers disk page files. If the free memory is too small, the memory may be insufficient or leaked. You need to monitor and analyze the system based on the actual situation.
Disk I/O problem analysis: Disk I/O is more likely to become a bottleneck for database servers, file servers, and streaming media servers. Generally, analyze disk I/O based on the following aspects:
The number of I/ OS per disk can be compared with the disk I/O capability. If the calculated number of I/ OS per disk exceeds the nominal I/O capability of the disk, it indicates that the disk has a performance bottleneck.
Monitor disk read/write operations. If a large amount of data is read/write operations for a long time and the CPU wait exceeds 20%, the disk I/O is faulty. Improve the disk I/O performance.
Network bandwidth problem analysis: The primary condition to determine whether network bandwidth is the bottleneck of system performance is whether network bandwidth will affect the performance of system transaction execution. For example, if the network bandwidth is reduced, the number of concurrent users, response time, transaction pass rate and other performance indicators are unacceptable. Or increase the network bandwidth, the number of concurrent users, response time, transaction pass rate and other performance indicators will be significantly improved.
During the actual performance test, if the connection times out is always reported, you can ping the IP address of the application server or gateway. If severe network delay or packet loss occurs, the network is unstable, and you need to check the network.
Based on the analysis of resource indicators, it is found that all aspects are interdependent and cannot be checked in isolation from a single aspect. When one aspect of performance problems, often can cause other aspects of performance problems, for example, a large number of disk reading and writing is bound to CPU and I/o resources consumption, and memory deficiency can lead to frequent for pages written to disk, disk write the operation of the memory, disk I/o bottleneck, at the same time, a large amount of network traffic can cause the CPU overload, so, When analyzing a performance problem, you need to consider all aspects.
Software performance testing is a continuous process of execution, monitoring, analysis, and tuning. Monitoring is to provide more reference data for analysis, and analysis is to perform tuning. As a result of analysis, tuning needs according to the specific issues specific analysis, this article does not do too much, only to monitor the key indicators of general analysis, advice in the practical work can be from two aspects of resource index and index system, layer upon layer detection, screening, performance problem is nowhere to hide, once you find the cause of the problems, performance problem is solved!