From d75c6fa0b4d8bc69a2be2a563fd3d9d74fd247a9 Mon Sep 17 00:00:00 2001 From: richjohnrambo Date: Wed, 30 Sep 2026 10:51:56 +0800 Subject: [PATCH] docs: record async push load regression --- .../IM-单机60%容量压力测试结果-20260929.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/docs/test/IM-单机60%容量压力测试结果-20260929.md b/docs/test/IM-单机60%容量压力测试结果-20260929.md index 2c0e393..f803091 100644 --- a/docs/test/IM-单机60%容量压力测试结果-20260929.md +++ b/docs/test/IM-单机60%容量压力测试结果-20260929.md @@ -204,3 +204,43 @@ Run ID：`s60-group-r2-0929`。 - `im_internal_queue_enqueue_total{queue="topic_presence_deferred"}` 发版后先复测精确 600 人群，确认基线无回归；再复测精确 900 人群。900 人验收要求：900/900 ACK、810000/810000 实时投递、0 断连、0 持久化缺失，`topic_client/topic_server/push_dispatch` 无 full，Topic queue wait P95 不超过 500ms，ACK P95 不超过 500ms，投递 P95 不超过 1s。渐进下线结束后 deferred presence 必须回落到 0，且不得出现 `topic_server full`。 + +## 14. 异步推送发版后精确 600 人回归 + +Run ID：`s600m-pushfix-r1-0930`。测试使用精确 600 人群 `grpJZjWbOek928`，A/B 各建立 300 条连接；两端均完整运行至 5 分钟落库沉淀、历史回查和 240 秒交错关闭结束，没有提前终止连接。 + +| 指标 | 结果 | +|---|---:| +| 就绪连接 | 600 / 600 | +| 发送尝试 / 收到 ACK | 600 / 523 | +| 发送结果未知 | 77（71 timeout、6 socket） | +| 服务端实际接收并落库 | 593 / 600 | +| ACK P95 | 17522.536ms | +| ACK 台账实时投递 | 308745 / 313800 | +| 实时到达率 | 98.3891% | +| 实时缺口 | 5055，全部可从历史补回 | +| 历史回查 | 593 / 593 | +| 无 ACK 但历史可查 | 70 / 70 | +| MySQL 精确命中 | 593 / 593 | +| MySQL 缺失 / 错配 / 重复 / 额外 | 0 / 0 / 0 / 0 | +| 断连 | 34（21 reset、13 abnormal close） | +| 重启 | 0 | + +异步推送改造本身没有形成服务端队列瓶颈。群主 Pod 处理的 600 次发布 Topic queue wait 全部不超过 50ms；593 次异步推送均成功入队，`push_dispatch` 没有 full，队列等待 P95 不超过 0.5ms，dispatch P95 不超过 10ms、最大不超过 25ms，deferred presence 最终为 0。Kafka lag 仍为 0。 + +本轮 77 条 ACK 未知中，70 条已被对端 WS 观察并精确落库，剩余 7 条 socket 失败未进入服务端。由此可确认本轮失败发生在客户端连接和 ACK 返回链路，不是消息持久化、Kafka 消费、Topic 排队或异步推送丢弃。 + +测试期间 3 个 IM Pod 持续收到培养服务文件确认请求，并在 `store.Files.LinkAttachments` 中对 `cvp...` 业务保留键调用 `types.GetTopicCat`，约每 5 秒产生一轮 HTTP panic 和完整堆栈。该接口允许业务保留键，不能按 Tinode Topic 强制分类；持续 panic 日志和并发异常请求污染了本轮环境，因此本轮不能作为异步推送改造的有效 600 人基线。 + +已完成两项修复： + +1. 附件关联仅对 `usr...` 用户引用执行用户 Topic 转换，`cvp...` 等业务保留键直接按普通关联键落库，消除确定性 panic。 +2. `verify-db` 将双机共同观察到的无 ACK 消息与 ACK ledger 合并去重。本轮修正后的独立 SQL 结果为 `expected=593, found_exact=593`，不再把 70 条已落库的 ACK 超时消息误报为 unexpected。 + +下一轮必须在上述修复发版后重新执行相同的精确 600 人场景。验收前先确认 3 个 Pod 不再出现 `invalid topic type for name 'cvp...'`；随后要求 600/600 ACK、360000/360000 实时投递、MySQL 600/600 精确命中、0 断连，并保持 Topic、push dispatch、Kafka 和数据库指标无积压。 + +新增产物： + +- `loadtest/im-pressure/results/s600m-pushfix-r1-0930/report.json` +- `loadtest/im-pressure/results/s600m-pushfix-r1-0930/db-verification.json` +- `loadtest/im-pressure/results/s600m-pushfix-r1-0930/server-metrics/`