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

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

最初的start_viewer是这样的：

bash 复制代码

start_viewer() {
  ---snip---

  (
    cd build || exit 1
    AWS_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---
  
}

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

bash 复制代码

  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修改如下：

bash 复制代码

start_viewer() {
  ---snip---
  
  (
    cd build || exit 1
    AWS_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

bash 复制代码

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，这样即有"任务内部等待"也有"调度间隔"。

最终代码如下：

bash 复制代码

start_viewer() {
  ---snip---
  
  (
    cd build || exit 1
    AWS_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---