docker容器性能压测需围绕真实业务负载、容器运行特征与资源边界系统验证稳定性与瓶颈，核心是测得准、看得清、调得对；须明确测试目标与边界条件，分层使用工具采集指标，并闭环执行压测反馈。
Docker 容器性能压测不是单纯“跑个高并发”，而是围绕真实业务负载 + 容器运行特征 + 资源边界约束，系统性验证稳定性与瓶颈。核心在于：测得准、看得清、调得对。
容器压测必须明确测试目标和边界条件
压测前不定义清楚“测什么”和“在什么条件下测”，结果就不可复现、难归因。
- 明确业务场景：是 API 接口吞吐？传感器数据上报延迟？还是批量任务处理时长？
- 锁定容器配置：CPU 限制（
--cpus=1.2）、内存上限（--memory=1g）、网络模式（--network=host还是bridge）必须与生产一致。 - 设定基线参照：比如原生进程启动耗时 120ms，那容器启动时间超过 300ms 就需关注；CPU 波动 ±5% 是健康态，±20% 就可能暴露调度或争抢问题。
用对工具链，分层采集关键指标
单一工具无法覆盖容器全链路，需组合使用、各司其职：
-
施压层：用
wrk（HTTP）、JMeter（协议丰富、支持分布式）、stress-ng（底层资源压榨）模拟真实负载。- 示例：
wrk -t8 -c400 -d60s http://localhost:8080/api/data（8线程、400连接、持续60秒）
- 示例：
-
容器层监控：
docker stats --no-stream实时抓取 CPU %、内存 RSS、网络收发量、块 I/O，每秒采样可导出 CSV 分析趋势。 -
宿主机/内核层：
top、iostat -x 1、sar -n DEV 1补充看网卡饱和、磁盘 await、上下文切换等深层瓶颈。 - 应用层埋点：在代码中打时间戳（如从接收到响应），测量端到端延迟，避免被容器网络或调度掩盖真实业务耗时。
关注 5 类典型瓶颈指标并快速定位
压测中一旦出现性能下滑或失败，优先排查以下维度：
-
启动延迟异常：
docker run启动超 2 秒？检查镜像体积（是否含无用依赖）、存储驱动（overlay2 vs devicemapper）、DNS 配置（/etc/resolv.conf是否指向慢 DNS）。 -
CPU 利用率突增但吞吐不升：可能是锁竞争或 GC 频繁，用
docker exec -it <container> top</container>看单进程 CPU 占比，结合jstack（Java）或pprof（Go）进一步分析。 -
内存持续增长直至 OOMKilled：用
docker stats观察MEM USAGE / LIMIT比值，配合docker exec -it <container> cat /sys/fs/cgroup/memory/memory.usage_in_bytes</container>确认实际 RSS；检查是否有内存泄漏或缓存未释放。 -
跨容器通信延迟飙升：若用
bridge网络，延迟从 5ms 增至 40ms，优先改用--network=host对比；若仍高，查宿主机 iptables 规则、conntrack 表溢出（conntrack -S）。 -
I/O 等待高、吞吐上不去：
iostat显示%util接近 100% 或await> 50ms，说明磁盘成为瓶颈；容器内日志写入、数据库临时文件、频繁小文件读写都可能触发，考虑挂载 SSD 卷或调整--io-maxbps限速反向验证。
压测过程要闭环：执行 → 记录 → 对比 → 优化 → 验证
一次有效压测不是“跑完就结束”，而是形成完整反馈环：
- 固定压测脚本（如 JMeter
.jmx文件 + 参数化 CSV），保证每次条件一致； - 自动采集
docker stats日志 + 应用日志 + Prometheus 指标，时间对齐后做关联分析； - 对比不同配置下的同一指标（如
--cpus=1vs--cpus=2下 P95 延迟变化）； - 每次只改一个变量（例如只调内存 limit，不动 CPU），避免多因干扰；
- 优化后必须重跑相同压测用例，确认改进有效且无副作用（如内存调低后 CPU 使用率反而飙升）。
不复杂但容易忽略
