From 097b028a195a16a582e9e0d2258f8689bdffd99d Mon Sep 17 00:00:00 2001 From: richjohnrambo Date: Wed, 30 Sep 2026 11:53:59 +0800 Subject: [PATCH] docs: record exact 600 regression runs --- .../IM-单机60%容量压力测试结果-20260929.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/docs/test/IM-单机60%容量压力测试结果-20260929.md b/docs/test/IM-单机60%容量压力测试结果-20260929.md index f803091..bb4c6b3 100644 --- a/docs/test/IM-单机60%容量压力测试结果-20260929.md +++ b/docs/test/IM-单机60%容量压力测试结果-20260929.md @@ -244,3 +244,55 @@ Run ID：`s600m-pushfix-r1-0930`。测试使用精确 600 人群 `grpJZjWbOek928 - `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/` + +## 15. Panic 修复后精确 600 人连续复测 + +部署提交 `06e08a6` 后，3 个 Pod 使用同一镜像摘要，均为 Ready、零重启。连续观测和三轮压测期间不再出现 `invalid topic type for name 'cvp...'` 或对应 HTTP panic，确认培养文件关联修复生效。 + +为区分代码回归与公网瞬态，使用同一配置和精确 600 人群连续执行 R2、R3、R4。每轮 A/B 各 300 连接，保持到 5 分钟沉淀、历史验证和 240 秒交错关闭全部完成。 + +| 指标 | R2 | R3 | R4 | +|---|---:|---:|---:| +| ACK | 600 / 600 | 600 / 600 | 600 / 600 | +| 实时投递 | 359400 / 360000 | 360000 / 360000 | 360000 / 360000 | +| 断连 | 1 次 timeout | 0 | 0 | +| 历史回查 | 600 / 600 | 600 / 600 | 600 / 600 | +| MySQL 精确命中 | 600 / 600 | 600 / 600 | 600 / 600 | +| MySQL 缺失 / 错配 / 重复 | 0 / 0 / 0 | 0 / 0 / 0 | 0 / 0 / 0 | +| ACK P95 | 314.530ms | 1555.109ms | 6228.311ms | +| 投递 P95 | 500ms 桶内 | 2000ms 桶内 | 10000ms 桶内 | + +R2 唯一异常是 `lta0259` 到 `216.236.31.189:443` 的一次客户端读超时。该连接在发送阶段开始后自动恢复，因此该账号错过 600 条实时消息；600 条均可从历史补回，服务端和 MySQL 没有丢失。R3、R4 均达到消息正确性全通过：零断连、零实时缺失、零重复、零乱序、零持久化缺失。 + +R3、R4 的延迟门禁没有通过，但服务端分段指标未出现同步恶化： + +- Topic queue wait P95 不超过 0.5ms。 +- 消息保存 P95 不超过 25ms。 +- push dispatch P95 不超过 10ms，队列无 full，完成后深度为 0。 +- WS send queue wait P95 约 3ms，socket write 超过 99% 不超过 0.5ms。 +- deferred presence 当前深度为 0。 +- 600 条历史和数据库记录全部精确命中，Kafka 未出现消费积压。 + +ACK 延迟按 3 个拨号 IP 分组后同步上升，不集中于单一入口。R2 三个 IP 的 ACK P95 为 302–372ms，R3 为 1536–1643ms，R4 为 5999–6559ms，说明延迟发生在服务端 socket write 之后的共享公网、负载均衡或压测机接收链路。 + +压测结束后的网络基线同样异常： + +| 入口 IP | TCP connect 平均 | HTTPS TTFB 平均 | ICMP 丢包 | ICMP RTT | +|---|---:|---:|---:|---:| +| `216.236.31.189` | 179ms | 623ms | 10% | 平均 256ms，最大 511ms | +| `216.236.31.191` | 178ms | 543ms | 10% | 平均 154ms | +| `64.118.158.131` | 178ms | 588ms | 0% | 平均 168ms | + +三条静态路由均经 `en1` 和网关 `192.168.1.1` 直连，没有经过 VPN/TUN。当前公网 RTT、丢包和 HTTPS TTFB 已高于或接近 500ms ACK 门禁，TCP 重传会进一步放大 WebSocket 队头等待。因此本组结果可证明精确 600 人下服务端消息正确性和持久化能力通过，但不能证明公网端到端延迟 SLA 通过。 + +后续在进入精确 900 人测试前，应先满足以下任一条件： + +1. 使用与测试集群同地域、低丢包的压测机，并保留当前 500ms/1s 延迟门禁。 +2. 取得 Ingress/LB 的 upstream、出站带宽、连接 reset 和重传指标，将公网延迟与服务端处理延迟分开验收。 +3. 双机正式压测时分别记录本机到 3 个入口的 RTT、丢包和 HTTPS TTFB；网络基线不合格时只验收正确性，不输出容量延迟结论。 + +新增产物： + +- `loadtest/im-pressure/results/s600m-pushfix-r2-0930/` +- `loadtest/im-pressure/results/s600m-pushfix-r3-0930/` +- `loadtest/im-pressure/results/s600m-pushfix-r4-0930/`