当前位置：首页 > ds >正文

AWS WebRTC 并发 Viewer 拉流失败分析：0.3 秒等待为何如此关键？

ds 2025/7/17 6:23:31

前面的文章介绍了，在并发启动viewer的时候拉流失败，解决方法是在启动每个viewer后给它留0.3秒的初始化时间，这0.3秒是如何体现的呢？

最初的start_viewer是这样的：

start_viewer() {---snip---(cd build || exit 1AWS_ACCESS_KEY_ID="$ak" AWS_SECRET_ACCESS_KEY="$sk" AWS_SESSION_TOKEN="$token" \AWS_DEFAULT_REGION="cn-north-1" AWS_KVS_LOG_LEVEL=1 DEBUG_LOG_SDP=TRUE \nohup ./samples/kvsWebrtcClientViewer "$channel" > "$log_file" 2>&1 &) || echo "Failed: $channel" >> "$ERROR_LOG"---snip---}

最初的并发启动命令是这样的：

  parallel --delay -j "$MAX_PARALLEL" --colsep ' ' start_viewer {1} {2} < "$TASK_FILE"

按照原先脚本启动，速度很快，每个viewer启动时间大概在20毫秒左右，这20毫秒就是从入口parallel开始，执行完start_viewer方法里包含的命令，继续执行下一个，最多同时有5个（可配置）进程在启动viewer，根据这个过程理解，viewer的启动间隔很短，两个viewer之间可能存在资源竞争，例如，端口竞争，导致启动失败，可以理解为初始化失败，按照这个思路想，如果初始化时间稍微充足一些可能会好一点。那么初始化时间放在哪个位置合适呢？

如果把 sleep 放在子 shell 内部，其实是无效的对主流程没有任何延迟效果，因为子 shell 是后台运行的。

sleep 要在子 shell外面执行才有效，因为上面用的是一个子 shell ()，里面的 sleep 不会阻塞主脚本。

于是start_viewer修改如下：

start_viewer() {---snip---(cd build || exit 1AWS_ACCESS_KEY_ID="$ak" AWS_SECRET_ACCESS_KEY="$sk" AWS_SESSION_TOKEN="$token" \AWS_DEFAULT_REGION="cn-north-1" AWS_KVS_LOG_LEVEL=1 DEBUG_LOG_SDP=TRUE \nohup ./samples/kvsWebrtcClientViewer "$channel" > "$log_file" 2>&1 &) || echo "Failed: $channel" >> "$ERROR_LOG"# 让主脚本稍作等待，确保 viewer 有时间完成初始化sleep 0.2  # 可以根据需要调整时间（单位：秒）---snip---
}

在压测场景下加一点微小的 sleep 有以下好处：
（1）避免并发瞬时峰值过高（尤其开 200+ viewer 时）
（2）给 viewer 程序初始化和拉流一点喘息空间
（3）更平滑地利用 CPU 和网络资源

这是第一步优化，还有第二步：
控制整体并发速率，使用 parallel --delay 0.2

parallel --delay 0.2 -j "$MAX_PARALLEL" --colsep ' ' start_viewer {1} {2} < "$TASK_FILE"

参数说明

–delay 0.2：表示每启动一个任务延迟 0.2 秒，即每隔 200 毫秒再启动下一个。
-j “$MAX_PARALLEL”：控制最大并发数，比如并发 5 个（可配置）。
–colsep ’ '：列分隔符为空格，匹配你任务文件中格式为：channel index。

使用 parallel --delay 0.2 的作用：
在需要启动大量 viewer 时（如 200 个以上），–delay 0.2 可以平滑拉起进程，减小瞬时 CPU 与网络资源压力，减少 viewer 启动失败的概率。

–delay 0.2 跟在代码里添加sleep 0.2 效果是一样的吗

–delay 0.2 和 sleep 0.2 在目的上相似，但在机制和影响范围上是不同

parallel --delay 0.2 作用：
（1）控制的是「parallel 启动任务的节奏」，每启动一个新任务（也就是每个 viewer），间隔 0.2 秒。
（2）是对任务调度层面的节流。控制的是启动密度（“节流”效果好）。
（3）一般用于避免短时间内启动太多进程造成系统瞬时压力过大。让任务错峰启动，避免同时启动过多任务导致系统过载（例如瞬时 CPU 或带宽暴涨）。
（4）每启动一个新任务之间，都会延迟 0.2 秒。就是说每两个任务之间插入 0.2 秒的间隔，而不是只在第一次启动前延迟。
（5）如果我设置了 -j 10 并且任务数远大于 10，–delay 控制的就是新任务的分发节奏（即进程结束后空出的位置才会延迟后再补位）。
优点：
（1）延迟只在任务之间起作用，不影响每个任务内部的执行速度。
（2）实际上更轻量、高效且不影响 viewer 的拉流逻辑。
（3）适合大量短启动、多任务并发场景。
sleep 0.2（放在 start_viewer 脚本内部）作用：
（1）控制的是「每个 viewer 启动过程中暂停 0.2 秒」，也就是每个任务自己执行时主动 sleep。
（2）是对 viewer 本身的执行逻辑添加等待。
影响：
（1）所有 viewer 无论是否被调度晚了，每个都会先 sleep，所以整个启动过程会更慢。
（2）不节流任务调度，而是拖慢每个任务本身。
优点：
（1）如果想确保 viewer 启动命令有时间稳定运行几百毫秒，这是比较合适的做法。
（2）控制每个 viewer 启动后等待一下，确保就绪或资源初始化。
（3）适合某些进程刚启动时占用资源波动大的情况。

在大规模启动 viewer 的压测场景中，如果想确保系统启动负载平稳和 viewer 有时间初始化，两者可以搭配使用，所以综合以上两种方案，在start_viewer内部sleep 0.2，在parallel上延迟0.1，这样即有“任务内部等待”也有“调度间隔”。

最终代码如下：

start_viewer() {---snip---(cd build || exit 1AWS_ACCESS_KEY_ID="$ak" AWS_SECRET_ACCESS_KEY="$sk" AWS_SESSION_TOKEN="$token" \AWS_DEFAULT_REGION="cn-north-1" AWS_KVS_LOG_LEVEL=1 DEBUG_LOG_SDP=TRUE \nohup ./samples/kvsWebrtcClientViewer "$channel" > "$log_file" 2>&1 &) || echo "Failed: $channel" >> "$ERROR_LOG"sleep 0.2---snip---}---snip---parallel --delay 0.1 -j "$MAX_PARALLEL" --colsep ' ' start_viewer {1} {2} < "$TASK_FILE"---snip---