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---
相关推荐
DexterLien5 小时前
API Gateway HTTP API 控制客户端访问 IP 源
http·gateway·aws·lambda·authorizer
阿里云大数据AI技术7 小时前
Post-Training on PAI (4):模型微调SFT、DPO、GRPO
人工智能·算法·云计算
在云上(oncloudai)7 小时前
深入解析 AWS RDS Proxy
aws·aws rds proxy
苹果企业签名分发7 小时前
腾讯云适配市面上哪些系统
云计算·腾讯云
运维开发王义杰7 小时前
解密AWS VPC路由表:显式关联与隐式关联,谁决定了网络出口?
网络·云计算·aws
AWS官方合作商7 小时前
如何连接 AWS RDS 数据库实例
数据库·云计算·aws
HCIE考证研究所1 天前
考完数通,能转云计算/安全方向吗?转型路径与拓展路线分析
网络·安全·华为·云计算·网络工程师·华为认证·数通
nbsaas-boot1 天前
如何设计一个合理的 Java Spring Boot 项目结构
java·运维·云计算
Akamai中国1 天前
为何说分布式 AI 推理已成为下一代计算方式
人工智能·分布式·云计算·边缘计算·云服务·akamai