Docker exec 与容器内常驻服务压测结论

关键结果

四种方式说明

这四种不是四个互斥产品方案，而是把问题拆开看： 先看老办法执行 true 有多慢，再看长连接只发空请求有多快，再看“仍然每条命令都执行一次 true”时能提升多少，最后看连续下发很多个 true 对大批量任务有没有帮助。

过程细节

• 每次都用 docker exec：每条命令都要重新联系 Docker，再进入容器，再启动命令。本次启动的命令是 true，它只会立刻成功退出。
• 常驻服务建连：测试中只用一次 docker exec 把常驻服务启动起来。之后常驻服务主动连到外部，后续命令都不再经过 Docker。
• 空请求回包：外部发 {"kind":"noop"}，服务收到后什么命令都不执行，马上返回成功。这个数字不能代表真实命令速度，但能说明长连接本身足够快。
• 执行 true：外部发 {"kind":"shell","cmd":"true"}，服务收到后在容器内启动 true。这个数字更接近真实的“远程下命令”。
• 连续下发：外部不等上一条 true 结束就继续发下一条。这样整体处理量更高，但单条命令可能要排队，所以等待时间会变长。

普通 Bridge 网络：box-bh

说明：“按真实总耗时折算”更适合看系统整体一秒能处理多少条；“中位等待、95% 等待、99% 等待”更适合看单条命令要等多久。

Host 网络：box-ba

判断

• 这次命令用的是 true，它本身几乎不耗时。所以慢点主要不在命令本身，而在“每次都重新通过 Docker 进去执行”这套固定流程。
• 长连接的价值是：只在启动时付一次进入容器的成本，后面一直复用这条通道。
• 如果只是轻量控制动作，最好直接写在常驻服务里完成，不要每次再启动新命令。
• 如果必须执行外部命令，连续下发能提高整体处理量，但单条命令等待时间会变长。

多个容器同时跑会怎样

又补了一组测试：同时启动 1、2、3 个容器内常驻服务，外部同时给它们下发命令。 每个容器各执行 3000 次 true；同时也测了一组“空请求回包”，用来观察长连接本身的压力。

结论：增加容器数量后，整体吞吐没有衰减，反而会上升；但不是完全线性上升。 例如执行 true 时，1 个容器约 1443 次/秒，2 个容器约 2016 次/秒，3 个容器约 3383 次/秒。 也就是说，总处理量提高了，但每个容器平均分到的速度会比单独跑时低一些。

原因也比较直观：多个容器同时跑时，宿主机 CPU、进程创建、网络收发、Python 调度都会一起竞争。 对空请求来说，单条等待从约 2 ms 增加到约 5 ms；对执行 true 来说，单条等待基本在 40-65 ms 区间。 所以如果目标是“总量更高”，多容器有帮助；如果目标是“单条命令尽快返回”，容器数量和同时下发数量都要控制。

复跑命令

uv run --with websockets python ws_daemon_bench.py \
  --container box-bh \
  --host 0.0.0.0 \
  --connect-host [内网地址已隐藏] \
  --count 5000 \
  --window 64 \
  --command true \
  --skip-docker-exec

uv run --with websockets python multi_daemon_bench.py \
  --containers box-bh,box-bos,box-ba \
  --count-per-container 3000 \
  --window 64 \
  --command true \
  --verbose