Beijing TiLiu Technology Co.,Ltd. TiTopStreamer Streaming Server Software

Location：Index Page > Document > Performance

Our technical team has conducted rigorous testing on the performance of Ti Top Streamer, resulting in test data for various hardware conditions and scenarios.

1. First, let me introduce the basic conclusion：

Ti Top Streamer is a high-performance, reliable, and stable streaming server software product that can meet the business needs of various high concurrency, 2K, 4K, and other scenarios, with extremely low physical memory usage.

Notes：After our comparative testing, the performance of Ti Top Streamer in CPU resource utilization is slightly inferior to SRS 3.0. Mainly because Ti Top Streamer has more business logic processing and related management functions. After all, Ti Top Streamer is a commercial product directly aimed at commercial customers.Just take a look at our management Web UI and SRS Web UI to understand this.

2. How did we test it?

The answer is ：Test Ti Top Streamer with Ti Top Streamer! In addition, some nodejs scripting tools were used as supplements.Here, A little explanation for this:

Ti Top Streamer has rich HTTP APIs that can be used to create large concurrent tasks. For a simple example, if testing 500 rtmp streams pushed to Ti Top Streamer, you only need to use the API to create 500 forwarding tasks for another Ti Top Streamer, The destination address for forwarding is the Ti Top Streamer you are currently testing!

The scripting tools that call these APIs can be implemented in any language, and we use the nodejs language. It's very simple. Basically, testing in a scenario can be completed with just 100 lines of node.js code.

3. Test data in various scenarios：

We know that streaming media servers have various different application scenarios. In different scenarios, different business processes and configuration parameters will inevitably affect the test results. For example, whether to enable HLS slicing and the length of the segment will affect CPU and memory usage, and the bitrate of the video stream will also affect CPU and memory usage.

So, first of all, we need to distinguish the technical scenarios for testing：

There are two ways to input an RTMP stream: 1) the external system initiates the flow and pushes it to the Ti Top Streamer using the RTMP protocol. 2) Ti Top Streamer initiates actively and pulls the RTMP stream externally based on an RTMP URL.

Is the consumption of CPU and memory the same under these two methods? Yes. After testing, the two are almost identical, with a difference of only about 1%, which can be ignored. The reason is also simple, because their difference is only that the signaling initiator is different (limited to the first second after the start of the test), Reception of media streams are exactly the same.

In this scenario, we tested several scenarios with and without HLS memory slicing enabled, as well as 750Kbps and 4Mbps bitrates：

Let's first take a look at the test result under the minimum hardware configuration (2-core 4G memory), as shown in the table below：

Hardware configuration： Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 1Gbps bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: No
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	11%~15%	0.8%	0.27	37Mbps
100 channels	20%~26%	1.3%	0.65	74Mbps
150 channels	31%~39%	1.7%	0.93	112Mbps
200 channels	46%~53%	2.1%	0.95	148Mbps
300 channels	68%~76%	3.2%	1.36	224Mbps

Notes: In all of our test data, the CPU usage will not exceed 80%, That is to say, in order to obtain stable and reliable operating data, we do not consider situations where CPU usage exceeds 80%. All test data in this article have adopted this principle, which will not be further elaborated below.

Next, let's take a look at how much resource usage will increase after enabling HLS memory slicing?

Hardwar configuration: Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 1Gbps bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: Yes (maximum slicing time 4 seconds, keeping the last 3 slices in memory)
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	14%~16%	5.6%	0.28	37Mbps
100 channels	25%~31%	10.8%	0.49	74Mbps
150 channels	38%~46%	16.4%	0.99	112Mbps
200 channels	53%~60%	20.9%	1.12	148Mbps
250 channels	68%~76%	23.5%	1.41	186Mbps

Notes：Ti Top Streamer adopts Cache technology in memory usage, That is to say, a cache range will be dynamically defined based on the actual usage of memory at the business level, The memory data above is actually the size of this cache, and the actual memory used at the business level is less than half of it. And the size of the cache will be dynamically adjusted according to the business situation.

Next, let's take a look at the average video bitrate of 4Mbps (also disable HLS memory slicing first), as follows：

Hardwar configuration：Ali Cloud ecs.sn1ne.large (2cores Intel 2.5GHz 4G Memery 1Gbps bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: No
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	50%~54%	1.6%	0.98	200Mbps
70 channels	68%~77%	1.8%	1.22	280Mbps

Next, let's take a look at how much resource usage will increase after enabling HLS memory slicing?

Hardwar configuration： Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 1Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: Yes (maximum slicing time 4 seconds, keeping the last 3 slices in memory)
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	55%~61%	23%	1.02	200Mbps
65 channels	72%~77%	30%	1.26	260Mbps

From the above data, it can be seen that the performance of Ti Top Streamer is still excellent at the lowest hardware configuration (2-core 4GB memory)

Next, we will double the hardware configuration (4-core 8GB memory) and perform the same test to see how the Ti Top Streamer performs :

Hardwar configuration：Ali Cloud ecs.sn1.large （4cores Intel 2.5GHz 8G Memery 1Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: No
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels/td>	7%~9%	0.4%	0.31	37Mbps
100 channels	13%~17%	0.6%	0.53	74Mbps
200 channels	30%~33%	1.0%	1.22	148Mbps
300 channels	39%~52%	1.4%	1.54	186Mbps
400 channels	58%~68%	1.8%	1.87	296Mbps
500 channels	69%~79%	2.1%	2.32	370Mbps

Next, let's take a look at how much resource usage will increase after enabling HLS memory slicing?

Hardware configuration: Ali Cloud ecs.sn1.large （4cores Intel 2.5GHz 8G Memery 1Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: Yes (maximum slicing time 4 seconds, keeping the last 3 slices in memory)
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	8%~11%	2.3%	0.35	37Mbps
100 channels	17%~20%	5.2%	0.63	74Mbps
200 channels	33%~39%	10.4%	1.34	148Mbps
300 channels	48%~57%	15.5%	1.78	186Mbps
400 channels	70%~75%	23.5%	2.25	296Mbps
420 channels	72%~78%	26%	2.58	315Mbps

Next, let's take a look at the average video bitrate of 4Mbps (also disable HLS memory slicing first), as follows：

Hardwar configuration：Ali Cloud ecs.sn1.large （4cores Intel 2.5GHz 8G Memery 1Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: No
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	32%~35%	0.7%	0.98	200Mbps
70 channels	44%~49%	0.8%	1.23	280Mbps
100 channels	63%~72%	1.1%	2.28	400Mbps
110 channels	71%~78%	1.2%	2.45	440Mbps

Next, let's take a look at how much resource usage will increase after enabling HLS memory slicing?

Hardwar configuration：Ali Cloud ecs.sn1.large （4 cores Intel 2.5GHz 8G Memery 1Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent RTMP input streams supported by Ti Top Streamer
Testing method: Simultaneously push rtmp stream to Ti Top Streamer, testing time: 5 minutes
Enable HLS memory slicing: Yes (maximum slicing time 4 seconds, keeping the last 3 slices in memory)
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of input streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of incoming data
50 channels	36%~39%	12.0%	0.99	200Mbps
70 channels	48%~56%	15.1%	1.34	280Mbps
100 channels	69%~78%	24.0%	2.51	400Mbps

Above, we have completed the testing of RTMP input, and under the most common lower hardware configuration (4-core 8G memory), the performance of Ti Top Streamer has reached the industry's first-class level!

We have also summarized some patterns:

1). Enabling HLS memory slicing does significantly increase memory usage, as slicing data needs to be saved in memory. But compared to our common large memory servers, this memory usage is negligible.

2). When the video bitrate increases, the CPU usage will increase, but the magnitude of the increase is limited. From 750kbps to 4Mbps, the CPU usage has only increased by less than 10% from the original level.

3). After the hardware configuration of the server is doubled, the supported business volume will not increase by double, but only by about 0.8 times. This situation can also be understood as a normal situation.

There are two ways to output RTMP streams: 1) external systems actively initiate and pull RTMP streams from Ti Top Streamer. 2) Ti Top Streamer initiates the push of video streams to an external server using the RTMP protocol.

Is the consumption of CPU and memory the same under these two methods? Yes. After testing, the two are almost identical, with a difference of only about 1%, which can be ignored. The reason is also simple, because their difference is only that the signaling initiator is different (limited to the first second after the start of the test), Reception of media streams are exactly the same.

In this scenario, we tested two scenarios: 750Kbps and 4Mbps:

Let's first take a look at the test result under the minimum hardware configuration (2-core 4G memory), as shown in the table below：

Hardware configuration： Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 2Gbps Bandwidth） CentOS7.4 64bit system
Test objective：Verify the number of concurrent RTMP output streams supported by Ti Top Streamer
Test method: Ti Top Streamer push rtmp stream to outside system, test time: 5 minutes
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of output streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of output data
50 channels	3.8%~4.2%	0.50%	0.14	37Mbps
100 channels	6.1%~6.5%	0.52%	0.17	74Mbps
200 channels	10%~12%	0.61%	0.19	148Mbps
300 channels	19%~23%	0.65%	0.23	222Mbps
400 channels	28%~33%	0.70%	0.42	296Mbps
500 channels	35%~38%	0.75%	0.74	370Mbps
600 channels	37%~41%	0.80%	0.88	444Mbps
700 channels	45%~49%	0.90%	0.92	518Mbps
800 channels	51%~53%	1.10%	0.99	592Mbps
900 channels	55%~61%	1.20%	1.26	666Mbps
1000 channels	65%~71%	1.32%	1.45	740Mbps
1100 channels	72%~78%	1.84%	1.72	814Mbps

Next, let's take a look at the situation where the average video bit rate is 4Mbps, as follows:

Hardware configuration： Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 2Gbps Bandwidth） CentOS7.4 64bit system
Test objective：Verify the number of concurrent RTMP output streams supported by Ti Top Streamer
Test method: Ti Top Streamer push rtmp stream to outside system, test time: 5 minutes
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of output streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of output data
50 channels	5%~6%	0.50%	0.15	200Mbps
100 channels	9%~11.5%	0.60%	0.19	400Mbps
200 channels	13%~16%	1.4%	0.21	800Mbps
300 channels	20%~25%	2.0%	0.25	1.2Gbps
400 channels	30%~38%	2.4%	0.46	1.6Gbps

Analysis: From this data, it can be seen that RTMP stream output occupies extremely low resources. Due to the limitations of the testing environment (Alibaba Cloud server bandwidth), we are unable to conduct further testing, but we can basically conclude that with this hardware configuration, there is no problem outputting 3Gbps data at all!

Next, we will double the hardware configuration (4-core 8GB memory) and perform the same test to see how the Ti Top Streamer performs：

Hardware configuration： Ali Cloud ecs.sn1.large （4cores Intel 2.5GHz 8G Memery 2Gbps Bandwidth） CentOS7.4 64bit system
Test objective：Verify the number of concurrent RTMP output streams supported by Ti Top Streamer
Test method: Ti Top Streamer push rtmp stream to outside system, test time: 5 minutes
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of output streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of output data
50 channels	2%~2.3%	0.30%	0.10	37Mbps
100 channels	3.5%~4.2%	0.31%	0.17	74Mbps
200 channels	7.0%~8.1%	0.32%	0.19	148Mbps
300 channels	10.1%~11.4%	0.33%	0.20	222Mbps
400 channels	13%~15%	0.40%	0.24	296Mbps
500 channels	13.2%~17%	0.70%	0.34	370Mbps
600 channels	18%~20%	0.80%	0.41	444Mbps
700 channels	22%~24%	0.85%	0.45	518Mbps
800 channels	25%~28%	0.91%	0.52	592Mbps
900 channels	29%~33%	1.06%	0.58	666Mbps
1000 channels	34%~37%	1.12%	0.62	740Mbps
1100 channels	40%~44%	1.24%	0.71	814Mbps
1200 channels	45%~49%	1.36%	0.79	888Mbps
1300 channels	50%~54%	1.40%	0.85	962Mbps
1400 channels	55%~59%	1.45%	0.91	1.01Gbps
1500 channels	60%~64%	1.53%	0.97	814Mbps
1600 channels	65%~69%	1.59%	1.03	1.08Gbps
1700 channels	70%~74%	1.64%	1.16	1.16Gbps
1800 channels	75%~79%	1.71%	1.23	1.23Gbps

From the above test results, it can be seen that the concurrency is quite considerable, after all, this is only a server with 4 cores and 8GB of memory.

Next, let's take a look at the situation where the average video bit rate is 4Mbps, as follows:

Hardware configuration： Ali Cloud ecs.sn1.large （4cores Intel 2.5GHz 8G Memery 2Gbps Bandwidth） CentOS7.4 64bit system
Test objective：Verify the number of concurrent RTMP output streams supported by Ti Top Streamer
Test method: Ti Top Streamer push rtmp stream to outside system, test time: 5 minutes
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of output streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of output data
50 channels	3%~4%	0.50%	0.11	200Mbps
100channels	4.2%~5.6%	0.51%	0.18	400Mbps
200 channels	6.0%~7.2%	0.61%	0.19	800Mbps
300 channels	8%~10%	0.65%	0.21	1.2Gbps
400 channels	11%~15%	0.69%	0.27	1.6Gbps

Analysis: Due to the limitations of the testing environment (Alibaba Cloud server bandwidth), we are unable to conduct further testing, but we can basically conclude that there is no problem outputting 5Gbps data for this hardware configuration!

The testing of HTTP streaming is very simple, after all, all you need to do is simulate HTTP downloading (decoding is a matter of the playback end, and it has nothing to do with our testing here). For Tip Top Streamer, it simply transmits HTTP streams externally, with little involvement in CPU computation or memory usage. So, we anticipate that this test will consume extremely low resources, does it meet our expectations? Please see the test result below：

Hardware configuration： Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 2Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent HLS output streams supported by Ti Top Streamer
Testing method: Download m3u8 and ts segment using nodejs script, testing time: 5 minutes
Encoding parameters: 750Kbps 512*288 H.264/AAC
Quantity of output streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of output data
100 channels	2.0%~2.5%	0.50%	0.05	74Mbps
200 channels	3%~3.4%	0.52%	0.06	148Mbps
400 channels	4.2%~5.0%	0.58%	0.07	296Mbps
600 channels	5.2%~6.4%	0.62%	0.10	444Mbps
800 channels	6.8%~7.5%	0.65%	0.12	592Mbps
1200 channels	8.5%~9.2%	0.70%	0.23	888Mbpss
1500 channels	11%~12%	0.80%	0.36	1.07Gbpss
2000 channels	20%~24%	1.20%	0.78	1.43Gbpss
2500 channels	30%~35%	2.45%	0.95	1.79Gbpss

Notes：Because the test focuses on HLS output capability, there is only one input stream in the test cases above (as you can see, there is almost no significant change in memory usage). If the number of input streams increases, the memory usage will definitely increase significantly. From the above test results, it can be seen that even at the lowest hardware configuration, the output capability of HLS is very powerful. Due to the limitation of the maximum bandwidth of the server, further testing is currently not possible. However, it can be expected that under this hardware condition, 4000 concurrent connections can be supported, and there is no problem reaching an output rate of 3Gbps.

We will continue testing to increase the video bitrate to 4Mbps. Other conditions remain unchanged, and the test result is as follows：

Hardware configuration： Ali Cloud ecs.sn1ne.large （2cores Intel 2.5GHz 4G Memery 2Gbps Bandwidth） CentOS7.4 64bit system
Test objective: To verify the number of concurrent HLS output streams supported by Ti Top Streamer
Testing method: Download m3u8 and ts segment using nodejs script, testing time: 5 minutes
Encoding parameters: 4Mbps 1920*1080 H.264/AAC
Quantity of output streams	CPU usage	Mem usage	Average load within 5 minutes	Average bitrate of output data
100 channels	3.0%~4.5%	0.50%	0.05	400Mbps
200 channels	5.0%~6.2%	0.52%	0.06	800Mbps
400 channels	8.2%~11%	0.58%	0.07	1.6Gbps

From the test results, it can be seen that the HLS concurrent output capability of Ti Top Streamer is very powerful, sufficient to meet the business needs of various application scenarios, but the bottleneck still lies in server bandwidth.

We have also conducted HTTP FLV testing, which is basically the same as HLS, with no significant changes. I won't go into too much detail here.

Finally, excellent test results have been achieved in the hardware configuration with a minimum of 2 cores and 4GB of memory, so we did not continue further testing on other higher servers.