Performance testing uses automated testing tools to simulate normal and abnormal scenarios to test various performance indicators of the system. Performance testing can analyze a system's capabilities, bottlenecks, key issues, etc. This article combines some scenarios of the live broadcast platform and uses the open source SRS-Bench tool to conduct stress testing on four live broadcast scenarios to test the basic capabilities of the live broadcast platform.
1. Introduction to performance evaluation tools
The scope of performance testing is wide, including load testing, stress testing, etc. Load testing can determine the maximum load that the system can withstand when the performance indicators are met. Stress testing can determine under what load conditions the system performance is in a failure state, and obtain system performance. The maximum service level provided. Generally, performance testing will be conducted before the system goes online. Currently, the more commonly used performance testing tools are divided into commercial testing tools and open source testing tools. The more commonly used ones are Loadrunner and JMeter. Loadrunner supports HTTP, windows Sockets, FTP, SMTP, and DNS protocols. JMeter is a Java-based open source stress testing tool developed for the Apache organization. It was originally used for web application testing and currently supports Web-http, https, SOAP/Rest, FTP, SMTP, POP3, IMAP, TCP and other protocols. The goal of this test is to test the capabilities of the live broadcast platform. Common domestic live broadcast protocols include RTMP, HLS, HTTP-flv, and RTP protocols. The tested live broadcast platform uses open source SRS and mainly supports three protocols: RTMP/HTTP-flv/HLS. Loadrunner and JMeter have poor support for the above protocols. If the secondary development workload is large, the survey found that the SRS-Bench tool can be used as a testing tool for multiple people to live broadcast at the same time, multiple people to watch at the same time, live to watch mixed scenes, and live to record 4 test scenarios.
2. Tool installation and use
1.Tool installation
Decompress the downloaded SRS-Bench source code package from https://github.com/ossrs/srs-bench in the Linux environment to be run. Use ./configure && make to install and compile. The objs directory will appear, which contains various The execution program of the stress testing tool (compilation may not be successful for some operating systems, but you can use it directly by copying the successfully compiled tool for other operating systems).
2.Tool usage
SRS-Benc mainly includes five tools: sb_rtmp_publish, sb_rtmp_load, sb_rtmp_load_fast, sb_hls_load, and sb_http_load. The specific usage can be viewed through the -h command.
3. Introduction to test environment
1. Live broadcast server
When testing the media performance of the live broadcast server, both single machine performance and cluster performance must be considered. Therefore, in this live broadcast server test environment, the performance of the single machine is first tested, and the deployment of the cluster environment is estimated based on the single machine performance and the business scenario.
2. Press
The press can start multiple push-pull flow processes, and each process can simulate up to 1,000 concurrent push-pull flows.
3. Network and load balancing
Servers and presses are all deployed in the same local area network. The local area network uses a gigabit network, and the network delay is negligible.
4. Test video files
The test video file uses the sample high-definition video wildlife.flv that comes with Windows. The video-related parameters are:
Audio: profile=LC, 2channels, 44100HZ
Video: profile=High, level=3.1, 1280x720
4. Test solutions under different live broadcast scenarios
1. Live broadcast by multiple people at the same time
Multi-person simultaneous live broadcast is actually multiple people pushing to the live broadcast server at the same time. SRS-Bench can be used to simulate concurrent push to a single node. The commonly used push protocol in the industry is the rtmp protocol. Use sb_rtmp_publish -i /home/aaa .flv -c 1000 -r rtmp://XXXX:1935/live/stream_1_{i} for testing. Please note that the setting of the room number should distinguish each process. After the pressure end executes sb_rtmp_publish, each push process will be printed out. Indicators include the number of concurrent push threads, number of successful alives, duration, and read and write traffic. The server can use the netstat command to view the number of push connections. Use the nmon tool to view server resource usage. Use pull during the test. The stream player randomly selects and plays multiple live streams to verify the success of streaming and playback lags.
After testing, when the number of push channels reaches a certain value, resource consumption is serious, the number of connections is lost, and video playback is severely lagging. It is recommended that a single node does not exceed 3,000 channels.
2. Multiple people watch the live broadcast at the same time
When multiple people are watching the live broadcast at the same time, if the CDN is connected, the player will choose the nearest CDN node for streaming. At this time, the streaming pressure is on the CDN; if the CDN is not connected, the player will pull the stream from the live source station, so it can Use sb_rtmp_load for testing. First, use the sb_rtmp_publish tool to simulate 1-channel push stream to the server. After confirming that it can be played, execute the command sb_rtmp_load -c 1000 -r rtmp://XXXX:1935/live/stream for testing. After testing, on the premise of basically ensuring the effect, it is recommended that the number of concurrent streams pulled by a single node does not exceed 3,000.
3. Mixed scenes
Due to the small scale of demand, some small live broadcast platforms neither connect to CDN nor set up separate edge nodes. They directly use the origin site for both push and pull streaming. Here, a single node is tested for performance with 500 to 1500 concurrent push and pull streams.
Taking 500 concurrent push and pull streams as an example, first use the sb_rtmp_publish tool to simulate 500 channels of push streams to the server, and execute the command:
sb_rtmp_publish -i /home/aaa.flv -c 500 -r rtmp://XXXX:1935/live/stream_{i}, select the number of people to stream each video according to the scenario, the script is as follows:
#! /bin/bash
for i in {0..499}
do
nohup ./sb_rtmp_load -c 1 -r rtmp://X.X.X.X:1935/live/stream_{i} >load.log&
done
After testing, when 1,500 live broadcast channels are pushed and pulled simultaneously, the server is under severe interruption load, and the actual playback effect is severely lagging. It is recommended that a single node in a mixed scenario does not exceed 1,500 channels.
4. Live recording
For some live broadcast scenarios such as training, meetings, etc., the live broadcast video needs to be saved for dissemination, retention, etc., and there is a need to record the live broadcast. First, configure the recording on the SRS server and configure the dvr under the vhost used:
dvr {
enabled on;
dvr_path /nas/record/[app]/[stream].[timestamp].flv;
dvr_plan session;
}After reloading the SRS configuration, use the sb_rtmp_publish tool on the stress test side to perform a concurrent push test. In addition to monitoring server resources, connection number, and live stream playback verification, the recording scene also needs to monitor the recording file size as a space evaluation criterion.
After testing, recording consumes a lot of CPU. It is recommended that a single node push and record no more than 500 channels. The recording file size per minute is 37.5M, which can provide a reference for disk space.
5. Conclusion
This article uses the open source SRS-Bench performance testing tool to perform a performance test on the open source SRS stand-alone live broadcast server, and discovers the capabilities of the stand-alone live broadcast platform through testing four scenarios, laying a solid foundation for the estimated resources and support capabilities of subsequent live broadcast platforms, and providing a strong support.
Finally: The complete software testing video tutorial below has been compiled and uploaded. Friends who need it can get it by themselves [guaranteed 100% free]
Software Testing Interview Document
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
