Establish repeatable message-pipeline capacity baselines

[ULookup]

Target Version

3.0-dev。复核基于 origin/3.0-dev 提交 a75fc8721b99e5c0b4421d0c58b5618bbe71ff31（PR #57）。PF-09 已为用户信息缓存建立专项门禁，但消息全链路容量基线仍缺失。

Evidence

• tests/perf/cache_test.go 已新增 BenchmarkPF09_UserInfoCache，验证 cold/L2/L1/stampede 状态、吞吐下限、baseline regression 和缓存指标完整性。
• tests/Makefile:53-67 与 .github/workflows/ci.yml:195-227 已提供 Linux perf-cache gate，可作为结构化性能契约的实现范式。
• PR feat(cache): harden Redis resilience and multilevel caching #57 的 service-artifacts 构建失败导致 perf-cache 被跳过，尚无绿色 CI artifact/趋势证据。
• tests/perf/send_msg_test.go 与 sync_test.go 仍只是 Go benchmark，没有并发/群规模矩阵、端到端持久化校验、尾延迟、错误率或资源采集。
• 通用 test-perf 仍没有消息链路阈值、结构化 artifact、环境指纹或批准基线比较。
• 当前仍无法回答热点会话、大群扇出、离线积压、MQ/DB/Redis/Push 饱和点和横向扩容效率。

Problem or Goal

复用 PF-09 的“固定场景 + 指标完整性 + 回归阈值”模式，建立可重复、可版本比较的消息链路容量基线，以吞吐、尾延迟、错误率、资源和正确性共同支撑高并发架构决策。

Scope

• 定义发送、持久化、同步、Push/ACK 的端到端场景与环境指纹。
• 覆盖并发档位、热点/多会话、1:1/小群/大群、在线/离线、多实例。
• 采集 QPS、成功率、P50/P95/P99/P999、MQ lag、DB/Redis latency、CPU、RSS、连接池和网络。
• 每个样本校验数量、唯一性、seq 单调和最终持久化。
• 保存机器可读 artifact、批准基线、回归阈值与趋势报告。
• 修复上游 artifact/build gate，确保消息与 PF-09 性能 job 可真实执行。

Non-goals

• 不承诺未经测量的生产绝对容量。
• 不用单次开发机 benchmark 作为发布结论。
• 不以平均延迟替代尾延迟。
• 不在无证据时直接实施 MySQL 分片、Redis 热点拆分或多地域架构。
• 不把 PF-09 缓存专项替代消息链路基线。

Acceptance Criteria

• 配置记录 commit、镜像/依赖、CPU/内存、实例数、数据规模、并发、持续时间与预热。
• 至少覆盖多会话、热点会话、小群、大群、离线积压和同步追赶。
• 每个场景输出吞吐、错误率、P50/P95/P99/P999、资源与依赖指标。
• 直接校验不重、不漏、seq 单调和最终持久化，正确性失败使结果失败。
• CI 实际执行并保存机器可读 artifact，与批准基线比较；回归需失败或显式审批。
• 报告给出第一个饱和资源、最大稳定吞吐和横向扩容效率。
• Add bounded backpressure across ingress, MQ, and Push #75 背压、队列分片和 Outbox 改造可用同一场景前后比较。
• PF-09 继续作为缓存专项门禁并共享环境/结果治理。

Test-first Plan

先增加基线合同测试与一个端到端 benchmark：

cd tests && go test -tags=perf ./perf/... -run TestPerformanceBaselineContract -bench BenchmarkMessagePipelineBaseline -benchmem -count=1 -benchtime=30s

预期 RED 是结果缺少环境指纹、尾延迟、错误率、正确性校验或结构化 artifact。最小 GREEN 是多会话发送的完整记录与验证；再扩展矩阵，并运行 Functional/Scenario 保证路径正确。

Risk and Security

性能测试会生成大量数据，必须隔离、限额和清理。artifact 不得包含 token、secret、消息正文或可识别用户数据；环境漂移和噪声范围必须进入基线判定。

Architecture Impact

No。建立测量与发布证据，不直接改变生产拓扑。

Core-flow Impact

No。测试调用并验证现有核心流程，不改变业务语义。

Required Skill Updates

• 更新 testing framework，记录消息基线、artifact 与回归审批。
• 更新 case catalog，登记消息 PF-* 场景与现有 PF-09。
• 更新 technology stack/repository map，登记性能入口、结果位置与 CI job。
• 更新 canonical performance operations 文档。