Performance Test Key Points
- Evaluate performance metrics — Thread TPS (architectable), throughput QPS (architectable), error rate (architectable), average response time (architectable)
- Simulate online data volume
- Understand whether the interface is cached or not, and if it is cached, it needs to be designed that the interface gets different data each time it is called
How do I estimate the number of interface threads to test?
-
For old projects:
- In the system, check the day in the past week (or a month) when the interface volume is the highest, and then find the time point (minute level) at which the interface volume is the highest. For example, if the interface volume is 10000 at 12:10, then we convert it to 10000/60 per second =166. Therefore, it can be determined that the TPS of this interface can be satisfied as long as it reaches 166
-
For new projects:
-
The algorithm of the 80/20 rule is 80% request / 20% time * redundancy coefficient (redundancy coefficient is generally between 2 and 5, generally take 3). For example, financial stock trading APP, generally from 9 am to 3 PM, 76060=25200 seconds, 10 million registered users, daily life of almost 100W, 80%= 80W, 80w/25200*3=95. The interface throughput is 95
-
Practical operation of pressure measurement
When determining the throughput indicator, depress the corresponding interface according to the indicator:
-
Pressure test setting parameters: Add thread group, thread number = user number /10; Ramp-up period Specifies the number of seconds in which all threads are started. The default value is 1 second. 0 indicates that all threads are started immediately. The number of cycles generally written forever, pressure test a 10-30 minutes, look at the report
-
Aggregate report: Samples number of requests issued, Average Average response time (ms) of a single Request, Error error rate, Throughput for short TPS, Throughput, number of requests processed per second.
-
Write interfaces. If multiple interfaces add regular expressions, connect the upper and lower interfaces in series
-
Run CMD to associate the database with jmeter logFile -o reportPath to obtain the report
Other performance indicators can reference (blog.csdn.net/ddxkjddx/ar…
Pressure measurement method corresponding to performance test indexes:
Estimated throughput = What method is considered for pressure measurement
- JM below 500 Note: If the interface throughput indicator is below 500, the JM meets the requirement
- 500-5000 JM distributed or LR
- More than 5000 central controllers + multi-machine deployment
- JM distributed: Configure parameter interface on JM, Jenkins configure multiple servers, one control machine, and multiple load machines, and add the key of the control machine to the load machine;
- JM+Grafana+Influxdb monitors performance parameters, memory, CPU usage, and interface throughput.www.cnblogs.com/uncleyong/p…
- Linux system
- memory
- Swap page swap space
free -m | sed -n '2p' | awk '{print "used mem is "$3"M,total mem is "$2"M,used percent is "$3/$2*100"%"}'
Copy the code
How can I view the performance bottleneck of an interface?
As TPS gets higher and higher, how to evaluate the QPS indicators of interface performance:
- The resource utilization of hardware and software gets higher and higher until the load is full (memory, CPU usage)
- Throughput increases until it peaks, declines, or stabilizes
- The response time will slowly increase beyond the throughput peak, and the response time curve will rise sharply (the interface processing speed will slow down dramatically as the software interface cannot handle ultra-high concurrency due to the full load of hardware resources)
So: the performance indicator is the value of the highest throughput, the response time slowly pulls up to the inflection point of the sharp pull up, and the hardware resources are the largest. The middle of the coordinate region of these three is the performance peak
How to optimize performance?
- The simplest add thread, process
- Database level, add index, add cache, some machine on the result of the cache, too much table data, table, SQL optimization
- When there is IO (network IO, disk IO), batch read, write, merge network requests, reduce the interaction with a single point
- More efficient implementation of the code, change the operation logic, such as the original account dimension to calculate the amount, change to the product dimension to calculate