RESAR 性能工程实战（一）：一小时、四台 ECS，搭起一个完整的性能实验场

RESAR 性能工程实战（一）：一小时、四台 ECS，搭起一个完整的性能实验场

📚系列目录（全部源码与原始实验日志：GitCode 仓库 https://gitcode.com/cpyaxjq/resar-perf-in-action ）
① 开篇：一小时四台 ECS 搭起完整性能实验场 ② 基准场景：wrk 压测与软中断证据链 ③ 容量场景：MySQL 索引优化与 sysbench 梯度压测 ④ 稳定性与异常：Redis 混沌工程四连击 ⑤ 性能结论：生产配置建议

《RESAR 性能工程实战》系列第 1 篇。本系列以真实云上环境贯穿始终：从环境摸排、业务模型、铺底数据，到基准 / 容量 / 稳定性 / 异常四大场景，最后落到运维能直接使用的性能结论。所有命令回显均来自真实执行，不做任何虚构。

一、为什么性能要从"测试"升级到"工程"

很多性能项目的现状是：拿几个接口压一压，出一份"TPS 5000、通过"的报告，就算交差。上线之后系统照样出事——因为这份报告回答不了运维真正关心的三个问题：

1. 系统最大容量到底是多少？（不是脚本里配置的并发数，而是拐点在哪）
2. 生产应该怎么配置资源？（多少 worker、多大 buffer pool、要不要缓存）
3. 出了异常系统会怎样，怎么恢复？（磁盘满了会发生什么？谁先死？）

RESAR 性能工程方法论的核心，就是让性能项目对这三个问题负责。它把性能项目拆成几个必须闭环的环节：

业务模型抽取 → 铺底数据构造 → 监控策略设计 → 场景执行 → 瓶颈证据链分析 → 性能结论输出 │ │ │ │ │ │ 符合生产 数据量级与 全局监控+ 基准/容量/ 决策树定位 最大TPS+ 业务比例 分布要真实 定向监控 稳定性/异常 而非猜测 配置建议+SOP

其中最容易被忽略、又最决定成败的，是四个"性能分析错误认知"：

本系列会用一个真实的四机实验场，把这些理念全部落地。

二、实验场设计：四台机器各司其职

选用 4 台华为云 FlexusX ECS（8vCPU / 16GiB / Ubuntu 24.04），内网互通，架构如下：

┌─────────────────────────────────────────┐ │ VPC 192.168.0.0/24 │ │ │ ┌──────────┐ 内网 │ ┌──────────────┐ ┌─────────────┐ │ │ M1 压力机 │─────▶│ │ M2 应用层 │────▶│ M3 数据库 │ │ │ wrk │ │ │ nginx:80 │ │ MySQL 8.0 │ │ │ sysbench │ │ │ gunicorn │ │ perfdb+sbtest│ │ │ .0.214 │ │ │ Flask :8000 │ │ .0.50 │ │ └──────────┘ │ │ .0.102 │──┐ └─────────────┘ │ │ └──────────────┘ │ ┌─────────────┐ │ │ └──▶│ M4 缓存/混沌 │ │ │ │ Redis 7 │ │ │ │ stress-ng/tc│ │ │ │ .0.226 │ │ └────────────────────────└─────────────┘──┘

分工原则：压力机与被测系统必须物理隔离（否则发压进程本身抢 CPU，数据全部失真）；数据库与应用分离（模拟真实链路的网络开销）；单独留一台做混沌注入（异常实验不干扰主链路）。

环境摸排：先看清机器再干活

任何性能项目的第一步都是环境摸排——你要压的到底是台什么机器？真实回显：

$ uname -a Linux ecs-5807-0001 6.8.0-106-generic #106-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux $ lscpu | grep -E '^(CPU\(s\)|Thread|Core|Socket)' CPU(s): 8 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 $ free -h total used free Mem: 14Gi 531Mi 14Gi $ df -h / /dev/vda1 40G 3.4G 35G 9% / $ ip -brief addr eth0 UP 192.168.0.214/24

注意两个细节：

• 8 vCPU = 4 物理核 × 2 超线程。后面分析"CPU 打满"时，超线程核的收益并不是线性的，这直接影响容量结论。
• 内网四台互 ping 全通、时延 <1ms，压测一律走内网 IP——弹性公网 IP 只有 5 Mbit/s 带宽，走公网压测第一秒就会把带宽打满，测出来的全是"假瓶颈"。

三、被测系统：一个迷你商城链路

为了覆盖"纯 CPU / 数据库 / 缓存"三种典型链路，应用层用 Flask 写了 4 个接口，gunicorn 承载、nginx 反代：

nginx 配置验证与首页可用性：

$ nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful $ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/ 200 $ curl -s http://127.0.0.1/api/health {"status":"ok","ts":1785306219.8953917}

四、铺底数据：量级和分布都要"像生产"

RESAR 特别强调铺底数据必须符合真实业务特性——空表上测出来的 TPS 毫无意义（索引全在内存、B+ 树只有一层）。本实验场的铺底：

• t_product商品表：524,288 行（用 19 次INSERT ... SELECT自倍增，2.9 秒完成）
• t_order订单表：1,000,000 行，user_id上故意不建索引——这是给容量场景埋的"真实瓶颈"
• sysbench 标准库 sbtest：4 表 × 10 万行

$ mysql perfdb -N -e "SELECT COUNT(*) FROM t_product;" 524288 $ mysql perfdb -N -e "SELECT COUNT(*) FROM t_order;" 1000000

倍增式造数是小实验场最快的铺底手段：先插 1 行种子，然后循环执行INSERT INTO t SELECT ... FROM t，行数按 2^n 增长，19 轮即 52 万行。生产级项目则应该用业务模型抽取出的真实分布（用户 ID 热点、订单状态比例）来造数，这个话题在第 3 篇展开。

五、工具链与监控策略

监控策略遵循"先全局、后定向"：全局计数器发现某类资源异常后，再用定向工具落到具体进程 / 中断 / 设备上，形成证据链。绝不允许"感觉是数据库慢"这种结论——必须有 EXPLAIN、有计数器、有前后对比。

整个搭建过程用 Python paramiko 写了个批量 SSH 执行器，四台机器并行 bootstrap，从裸机到全部就绪只用了 74 秒（apt 安装 + nginx/gunicorn/MySQL/Redis 配置 + 152 万行铺底数据 + sysbench prepare）。自动化不是炫技：性能实验经常要"重置环境重跑"，手工搭一次 30 分钟的环境，没人愿意重跑第二遍，而不可重复的性能数据不可信。

六、四大场景路线图

后续三篇的实验路线：

1. 基准场景（第 2 篇）：单接口测到最大 TPS。静态页 21.7 万 RPS 触顶的软中断证据链；gunicorn 2→8 worker 让 TPS 翻 2.37 倍的定位与验证。
2. 容量场景（第 3 篇）：sysbench 梯度加压找拐点；百万行表缺索引导致全表扫描，加索引后 28.3 倍加速的完整证据链；默认 128MB buffer pool 的配置陷阱。
3. 稳定性 + 异常场景（第 4 篇）：CPU 争用、2ms 网络延迟、内存淘汰、磁盘写满四连击，每个异常都给出"现象→证据→恢复"三元组。
4. 性能结论（第 5 篇）：把所有数据收敛成运维可执行的结论——最大 TPS、生产配置建议、告警阈值、故障 SOP。

一句话总结本篇：性能工程的第一步不是发压，而是把环境、数据、监控做到"像生产、可重复、有证据"。这三点做不到，后面测出来的所有数字都只是数字。

本文实验数据均来自真实环境实操（华为云 ECS，Ubuntu 24.04），命令回显未经修改，公网 IP 已脱敏。AI 辅助整理成文。