Article directory
I. Overview
1.1 Purpose
This test report is the performance test report of the web chat room, the purpose is to summarize the learning in the performance test phase, analyze the test results, and describe whether the website meets the requirements.
1.2 Background
Considering that the increase in the number of users and data will cause immeasurable pressure on the server, it is planned to test the load performance of the web chat room project. Under the condition that the system configuration remains unchanged, the performance of the server under high load within a certain period of time Behavioral performance, which facilitates correct analysis and evaluation of the system environment.
1.3 Scope
This test is mainly a performance test of the web chat room project.
Two test environment
| environment | machine type | operating system | CUP | Memory |
|---|---|---|---|---|
| client | LAPTOP-Q4342TA2 | windows10 | i5-11300H(x64) | 16.0 GB |
Three test content and method
3.1 Test objectives
Under the overload of a large number of users and data volume, obtain relevant data when the server is running, so as to analyze it, find out the bottleneck of the system, and improve the stability of the system.
3.2 Test content
This test is mainly to test the response speed and bearing capacity of the "login function" of the web chat room under heavy load.
3.3 Test tools
The main test tools are: JMeter performance test tool
Auxiliary software: screenshot tool, Word
Four GUI testing steps
4.1 Create a new thread group
Set related parameters: 1. Number of threads (number of virtual users) 2. Ramp-Up time (seconds): Set the start-up time of all users 3. Cycle times: The number sent by each thread
Here we first set 1000 * 3
4.2 to create a new HTTP request
We fill in the interface information and parameters of the test according to the interface document
4.3 Add appropriate assertions
When looking at the interface documentation, we found that if the response is successful, it will contain the "success":true string, so we add the corresponding settings
Add assertion result:
4.4 Add listener
Here we choose to view the result tree, aggregated report and graphical results
4.5 run
View the result tree:
Aggregate report:
Graphical result:
But during the test, I suddenly found this sentence in the command line running Jmeter, because the graphics tool also consumes a lot of resources, so we will test it again by using a simple data writer + HTML report DashBoard
Five Simple Data Writers + HTML Report DashBoard
4.1 Modify the data scale again
Increase the test pressure, modify the number of threads to 1000, and loop 10 times
5.2 Add a simple data writer
Modify the output path to a suitable directory, and change the file suffix to jtl ending
5.3 Generate HTML report
Click generate report
5.4 View reports
Six result analysis
6.1 Success rate
In the dashboard, we can see that in this test, the success rate is 90.06%, and the success rate is relatively low
6.2 Response time variation
Here we can see that the test request time has reached a terrifying 200,000+ms, which is unbearable for users, and the system response cannot meet expectations.
6.3 TPS
We can find that the number of transactions processed per second is also showing a downward trend
6.4 Response time
We can find that the response time of the whole system can be said to be very slow
6.5 Error messages
We can find that there are a lot of error messages here, and SocketException even reaches 80%
Seven performance optimization schemes
1. Server resource limitation: The server has limited processing capacity and cannot handle a large number of concurrent requests at the same time. When the number of concurrent requests exceeds the processing capacity of the server, the access speed will slow down or errors will result. During our performance test, we use the TOP command to check that the server CUP is always full, and a large number of requests cannot be processed at one time. The solution can be to increase the hardware resources of the server, such as increasing CPU, memory or bandwidth.
2. Improve the code business logic: Because we have a single-threaded operation to save the picture verification code to the server hard disk when logging in, this step is very time-consuming under high concurrency, and multi-threaded operations can be introduced later.
3. Database pressure: The interface needs to read the verification code id in the database. In the case of high concurrency, the load on the database will increase, which may slow down the access speed or cause errors. The pressure on the database can be alleviated by optimizing database queries, increasing database indexes, using caching technology, and sub-database sub-tables.
4. Correct use of the WebSocket protocol: During the performance test, a large number of SocketExceptions occurred, and subsequent investigations and corrections can be carried out in a targeted manner.