candidate is the address that RTC provides services to the outside. In certain deployment scenarios, we need to configure it in multiple ways.

This is also the only item that RTC must confirm the configuration for, while others can be left at their default settings.

For detailed configuration instructions, please refer to: https://github.com/ossrs/srs/wiki/v4_CN_WebRTC#config-candidate

TRANS_BY_GPT3

MacPro information:

• macOS Mojave
• Version 10.14.6 (18G3020)
• MacBook Pro (Retina, 15-inch, Mid 2015)
• Processor: 2.2 GHz Intel Core i7
• Memory: 16 GB 1600 MHz DDR3

Docker information:

• Docker Desktop 2.2.0.3(42716)
• Engine: 19.03.5
• Resources: CPUs 4, Memory 2GB, Swap 1GB

Note: SRS is bound to CPU0, Benchmark is bound to CPU2-3.

Note: The test video is still ./doc/source.200kbps.768x320.flv.

Note: The following tests are all Streams=1, meaning pushing one stream for multiple playback scenarios.

Baseline

Baseline without any optimization, the data is as follows:

SRTP-NASM

SRTP enabled openssl, and openssl enabled assembly, which means that SRTP encryption and decryption are optimized with assembly. Refer to 5e06a256. The data is as follows:

UDP sendmmsg + mw_latency

After enabling sendmmsg, multiple UDP packets can be sent at once. The data is as follows:

Remark: By default, RTC is configured for low latency, which means min_latency on; and play.mw_latency 0;, so the number of messages that can be written with each sendmmsg is not much. We will increase the latency to observe changes in performance.

Note: The queue (ms) below refers to mw_sleep, which is also known as mw_latency, which represents how many milliseconds the server actively queues (delays) before writing multiple packets at once.

Although the optimization of queues over 100ms may not be significant, I think there may be other bottlenecks. From the data above, it can be seen that sendmmsg is very useful for optimizing system performance.

Currently, the server queue is set by increasing the delay, also known as mw_latency. This allows the server to send more data at once, which is useful for TCP optimization. However, for UDP, especially in low-latency RTC scenarios, it is not advisable to increase the delay to improve performance. In fact, sendmmsg allows for sending data to multiple clients at once, and future optimization will be aimed in this direction.

TRANS_BY_GPT3