测试目标是定位镜像推送拉取的真实瓶颈，关键指标包括端到端耗时、网络吞吐量（MB/s或Gbps）、并发稳定性；需结合分层传输特性，在局域网闭环环境使用私有Registry、Docker 24.0+客户端及三类典型镜像开展单流、并发与混合读写压测，并重点识别网络路径、存储驱动、Registry配置及认证服务四层瓶颈。

明确测试目标与关键指标

镜像推送与拉取性能测试不是单纯比谁快，而是要定位真实瓶颈。重点看三项：端到端耗时（从命令敲下到完成）、网络吞吐量（mb/s 或 gbps）、以及并发稳定性（10节点同时拉取是否超时或失败）。尤其要注意分层传输特性——首次拉取大镜像可能耗时久，但第二次只拉新层，速度会明显提升；推送同理，registry 已有基础层时，仅上传差异部分。

搭建可控的基准测试环境

避免公网波动干扰，建议在局域网内构建最小闭环环境：

• 服务端：部署私有 Registry（如 Harbor 或原生 registry:2），运行在 SSD 存储+万兆网卡的物理机上，禁用 TLS 加密（测试阶段）以排除加解密开销
• 客户端：统一使用 Docker 24.0+，关闭 DNS 缓存（–dns 127.0.0.1 配合本地 dnsmasq 可控解析），绑定固定 MTU（–mtu 9000 若支持 jumbo frame）
• 镜像样本：准备三类典型镜像——轻量级（alpine:3.20，~6MB）、标准应用（nginx:1.25，~85MB）、重型多架构镜像（tensorflow/tensorflow:2.16.0-gpu，含 arm64/amd64 层，总大小 >2GB）

执行分层压力测试

不只测单次操作，要模拟真实负载场景：

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

• 单流极限吞吐：用 docker pull --platform linux/amd64 拉取大镜像，配合 iftop -P 5000（Registry 默认端口）实时抓取实际带宽，记录稳定峰值
• 并发拉取压测：启动 5/10/20 个容器并行拉同一镜像，观察 Registry 日志中 503 错误率、平均响应延迟（NGINX access log 中 $request_time）
• 混合读写干扰：一边持续拉取，一边用另一批客户端推送新标签（docker push registry/test:loadtest-$(date +%s)），验证 Registry 存储 I/O 和 Gitaly（若集成）是否成为瓶颈

识别并验证常见瓶颈点

实测中高频问题往往不在 Docker 客户端本身：

• 网络路径层：Bridge 网络默认 NAT 带来额外开销，改用 --network host 可提升吞吐 3–5 倍（参考 AI 训练平台案例）
• 存储驱动层：overlay2 在高并发小文件写入时易出现 inode 耗尽，需监控 df -i；生产环境建议配 overlay2.size=50G 限制单层上限
• Registry 配置层：默认 storage.backend=file 性能有限，换成 storage.backend=s3（对接高速对象存储）或 cache.layerinfo.enabled=true 可显著降低清单解析延迟
• 认证服务层：若启用 LDAP 或 OAuth2，每次拉取前需远程校验 token，建议开启 Redis 缓存认证结果（Harbor 支持 redis_url 配置）