前面的文章介绍了，在并发启动viewer的时候拉流失败，解决方法是在启动每个viewer后给它留0.3秒的初始化时间，这0.3秒是如何体现的呢？
最初的start_viewer是这样的：
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---
}
最初的并发启动命令是这样的：
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 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
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 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---