1.背景介绍

在 chromium 浏览器中使用 webrtc 实现点对点通信时，由于刚开始发送端虚拟机只分配了一个处理器核，接收端处理器性能足够，导致通过 webrtc 共享桌面的视频播放延时达到 4~6 秒，所以想试验一下，随着发送端处理器核数增加，webrtc 的延时有什么样的变化规律。
机器配置说明：

p2p	内核数	内存大小(G)
接收端	4核8线程	16
发送端	1——2——4	2——4——8

本文只对发送端的性能做测试，取的变量：
（1）当发送端虚拟机内存大小固定为 8G 时，内核数从 1 到 4 变化；
（2）当发送端虚拟机内核数固定为4时，发送端内存大小从 2G 到 8G 变化时。

备注：本文的统计数据取自接收端 webrtc 日志文件。

webrtc 日志文件记录的统计信息如下图：

2. 处理器内核

发送端虚拟机内存保持 8G 不变，改变处理器的核数，发送端播放在线视频，观察接收端延时情况。

2.1 共享音频

处理器核数	共享屏幕总时长（s）	音视频同步延时(ms)	解码时间（ms）	抖动缓冲区延时（ms）	当前延时（ms）	平均帧间延时（ms）	最大帧间延时（ms）
1	266	2034	2	966	774	139	9920
2	1708	285	2	190	203	35	5017
4	2108	996	2	97	112	35	415

2.2 不共享音频

处理器核数	共享屏幕总时长（s）	解码时间（ms）	抖动缓冲区延时（ms）	当前延时（ms）	平均帧间延时（ms）	最大帧间延时（ms）
1	235	2	545	168	243	10537
2	1660	2	113	126	35	5010
4	1853	3	69	83	36	388

2.3 小结

（1）数据分析

• 在单核的情况下，接收端视频无法观看，延时卡顿严重，播放一段时间就会卡死。
• 在双核的情况下，接收端视频比较流畅，延时在 1 秒以内，两端基本同步，可以正常观看，并且不会感到明显的延时。
• 在四核的情况下，接收端视频比较流畅，延时在 1 秒以内，两端基本同步，可以正常观看，并且不会感到明显的延时。

（2）小结
在使用 webrtc 进行屏幕共享时，发送端的处理器的核数最小为 2 ，这样共享屏幕才能基本可用。

3. 内存变化

发送端虚拟机处理器内核保持 4 核不变，内存大小取 2G， 4G, 8G，观察共享在线视屏时的接收端延时情况。

3.1 共享音频

内存大小(G)	共享屏幕总时长（s）	音视频同步延时(ms)	解码时间（ms）	抖动缓冲区延时（ms）	当前延时（ms）	平均帧间延时（ms）	最大帧间延时（ms）
2	1649	4504	3	165	180	39	1080
4	1740	584	3	113	127	35	980
8	2108	996	2	97	112	35	415

3.2 不共享音频

内存大小(G)	共享屏幕总时长（s）	解码时间（ms）	抖动缓冲区延时（ms）	当前延时（ms）	平均帧间延时（ms）	最大帧间延时（ms）
2	1697	3	148	163	37	1360
4	892	3	144	158	35	494
8	1853	3	69	83	36	388

3.3 小结

（1）数据分析
在发送端虚拟机内存大小为 2G 、4G 、8G ，接收端都可以正常的播放视频，感觉不到明显的卡顿或延时。
（2）小结
在使用 webrtc 点对点通信功能进行共享桌面时，通信延时对内存的变化不是很敏感。当然，内存越大效果越好，但是这种变化不像处理器那样明显。

4.结论

以上分析过程中并没有严格的控制变量，接收端主机处于正常工作状态，打开了较多的应用，一边通过虚拟机向主机共享屏幕，一边在主机上正常做开发的工作，并且长时间没有重启机器，可能导致负载处于波动状态，如果能够保证每一次测试之前的两端环境都是重置过的，实验数据会更有说服力，但是这样操作过于麻烦。
但是根据上面的数据还是可以得出一些简单的结论：
（1）在使用 webrtc 的点对点通信功能进行屏幕共享时，有基本的机器性能要求；
（2）发送端为虚拟机的情况下，处理器要双核及以上配置，内存 2G 以上（没有测 1G 的情况，因为 1G 内存已经很少见）；
（3）选用性能更好的 CPU，可以缩短延时，不过需要考虑成本问题。