diff --git a/docs/IM-006商户双机消息压力测试方案.md b/docs/IM-006商户双机消息压力测试方案.md index 644335f..f462e90 100644 --- a/docs/IM-006商户双机消息压力测试方案.md +++ b/docs/IM-006商户双机消息压力测试方案.md @@ -6,6 +6,8 @@ > 双机实际操作以 [`loadtest/im-pressure/README.md`](../loadtest/im-pressure/README.md) 为准。当前开发机固定为机器 A，负责数据准备、协调器、agent A、集中采集和最终报告；另一台机器固定为机器 B，只运行 agent B 并回传结果。 +> 当前测试环境实际企业码为 `allrich`，沿用本方案最初为 006 商户定义的账号规模、场景和统计口径。已完成的 200 对复测、故障根因和修复证据见 [`docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md`](./test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md)。 + 本次测试使用 006 商户的 2000 个账号，在两台压测机上各运行 1000 个在线 WebSocket 用户，验证多 Pod 场景下： 1. 1000 对 P2P 会话同时收发时，消息是否被接受、实时投递并最终持久化。 @@ -128,7 +130,7 @@ Idempotency-Key: 1. `max_subscriber_count >= 2500`。仓库配置默认是 128，必须在所有 Pod 上统一调高并滚动重启。 2. 006 商户 `max_group_members` 为 0（不限）或不小于 2000；目标群 `max_member_count` 同样满足要求。 3. IM Server 所有 Pod 版本和配置一致，原生 Cluster 成员数与 Running Pod 数一致。 -4. Kafka 的 P2P、群消息持久化 Topic 可写，消费组无持续积压，死信在基线时为 0。 +4. Kafka 的 P2P、群消息持久化 Topic 可写，消费组无持续积压，死信在基线时为 0；测试环境的 `im.message.persist` 和 `im.group.message.persist` 均为 3 分区、3 副本。 5. 两台压测机到目标入口网络稳定，文件描述符上限、临时端口和 NAT 容量足够。 6. 两台压测机使用 chrony/NTP，同一时刻的时钟偏差绝对值小于 5ms，否则跨机器单向延迟无效。 7. 每台压测机至少预留 2 CPU、4GB 内存和稳定的 100Mbps 网络；测试进程自身 CPU 不应长期超过 70%。 @@ -357,8 +359,8 @@ e2e_realtime_latency = t_data - sent_at | 群实时投递丢失率 | <= 0.001%，发布版本验收目标为 0 | | 重复投递率 | 0 | | Topic `seq` 回退 | 0 | -| ACK p95 / p99 | < 100ms / < 300ms | -| 实时投递 p95 / p99 | < 200ms / < 500ms | +| ACK p95 / p99 | <= 500ms / <= 1s；必须用原始 ACK 时间戳计算，不能用直方图桶上界代替 | +| 实时投递 p95 / p99 | <= 1s / <= 2s；跨机器时要求时钟偏差达标 | | `deliver/hub_full`、WS 写队列满 | 0 | | Kafka producer/commit 错误 | 0 | | Kafka 消费重试、单条降级、死信新增 | 0 | @@ -787,8 +789,33 @@ results//report.md 2. 完成 1000 对好友关系与 2000 人群，运行 `verify` 直到全部通过。 3. 先用 20 对 P2P、100 人群做冒烟测试，验证统计口径。 4. 执行 P0 热身。 -5. 执行 S1，等待服务端和 Kafka 恢复基线至少 5 分钟。 -6. 执行 S2，等待恢复基线至少 10 分钟。 -7. 执行 S3。 +5. P2P 按 200 对、500 对、1000 对逐级执行；每一级通过后才能进入下一级。 +6. 执行 S2 群聊，等待恢复基线至少 10 分钟。 +7. 执行 S3 混合场景。 8. 合并结果，按实时链路与持久化链路分别给出结论。 9. 全部稳定后再单独进行 Pod 重启、断网或 Kafka/Redis 故障注入，不与本轮无故障基线混跑。 + +### 14.1 P2P 容量阶梯 + +三个档位复用同一批账号和好友关系，只裁剪 runtime manifest，不重新注册或重复加好友。每档至少执行两轮；发布验收档建议执行三轮。任何一轮出现消息丢失、重复、乱序、非预期拒绝、数据库不一致或 Pod 重启，都必须停止升级并先定位。 + +| 档位 | A/B 用户 | WS 总数 | 每用户消息 | Publish 总数 | 目标 | +|---|---:|---:|---:|---:|---| +| P2P-200 | 各 200 | 400 | 10 | 4000 | 验证正确性、指标和基础延迟 | +| P2P-500 | 各 500 | 1000 | 10 | 10000 | 验证 Kafka 三分区、MySQL 和 Cluster 中档容量 | +| P2P-1000 | 各 1000 | 2000 | 10 | 20000 | 单聊发布验收 | + +每档的执行流程固定为：生成唯一 `run_id`；开始前采集至少 2 分钟基线；启动 coordinator；A/B agent 全部 READY；统一时间发压；P2P 发送结束后继续监听至少 30 秒；等待 Kafka lag 归零；执行历史回查与 MySQL `client_mid` 精确核验；发送结束后继续采集至少 5 分钟；最后合并报告。 + +每档升级门槛：Ready、Publish ACK、实时到达、历史查询和 MySQL 精确匹配全部达到期望数；丢失、重复、乱序、断连、403/502/503、Cluster queue overflow、Kafka retry/dead letter、MySQL deadlock、Pod 重启均为 0；Kafka lag 在发送结束后 60 秒内归零；Pod 无持续 CPU throttling。ACK P95 超标时必须按压测机分别报告，并先排除 DNS、TCP、TLS、WebSocket RTT 和时钟偏差。 + +### 14.2 P2P 通过后的业务场景 + +1. **GROUP-2000**：2000 条 WS 全部加入同一群，A/B 各 500 个发送者；每人发送 2 条，两轮合计 2000 条。实时投递期望量按每条消息的实际 Ready 接收者计算，并保留 60 秒 drain。 +2. **MIXED**：300 对私聊用户双方各发 5 条，共 3000 条私聊 Publish；同时 A/B 各 250 个群发送者每人发 2 条，共 1000 条群 Publish。 +3. **稳定性复跑**：GROUP 和 MIXED 至少各两轮，确认无冷启动偶然性。 +4. **故障注入**：分别执行单 Pod 滚动重启、Kafka 短暂不可用与恢复、Redis 短暂不可用与恢复；故障轮只验证恢复能力，不与无故障性能基线混合统计。 + +### 14.3 当前下一步 + +当前已通过 P2P-200 的消息正确性、Kafka 60 秒排空、MySQL 精确落库、零乱序、零审计死锁和零 CPU throttling。下一步执行 **P2P-500**：A/B 各取账号索引 `1..500`，共 1000 条 WS、10000 条 Publish。若连续两轮满足上述升级门槛，再进入 P2P-1000。