docs: record async push load regression
This commit is contained in:
@@ -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/`
|
||||
|
||||
Reference in New Issue
Block a user