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