# IM allrich 双机压测执行记录

日期：2026-09-27

## 1. 测试环境

| 项目 | 值 |
|---|---|
| 企业码 | `allrich` |
| 企业名称 | 大家一起发 |
| HTTP API | `https://api.118im.com` |
| WebSocket | `wss://api.118im.com/v0/channels` |
| API Key | 通过 `IM_API_KEY` 注入，不写入 Git |
| 测试验证码 | `123456`，仅测试环境使用 |
| 测试密码 | 通过 `IM_LOAD_PASSWORD` 注入，不写入 Git |
| 机器 A | 当前开发机，`192.168.1.135` |
| 机器 B | 另一台压测机，运行 `-machine b` |

`config.json`、`.env.test`、`manifest.json` 均被 Git 忽略。manifest 含账号 Token，只能通过受控内网传输。

## 2. 数据准备结果

2026-09-27 首次准备曾按 2000 账号目标执行。当前分阶段压测使用的实际运行文件为：

- `users_per_machine=500`。
- 账号：1000，机器 A/B 各 500。
- 好友关系与 P2P Topic：500 对。
- 测试群：1 个，当前 manifest 的 `group_topic=grp3Ita5tyBIMs`。

正式的 2000 人群测试前，必须将 `users_per_machine` 恢复为 1000，在机器 A 重新执行 `prepare` 和 `verify`，并将新 manifest 同步给机器 B。不能用当前 1000 人清单宣称已完成 2000 人群压测。

准备过程观察到注册和好友同意接口存在少量瞬时 500/404，100 人群邀请批次存在 502、超过 2 分钟及 `IDEMPOTENCY_IN_PROGRESS`。工具使用相同业务幂等键和退避重试后全部恢复；这些属于准备链路现象，不计入正式消息到达率。

## 3. 最新有效轮次

| 项目 | 值 |
|---|---|
| Run ID | `p2p500-r5-20260927-05` |
| 场景 | `p2p` |
| Git 提交 | `ea8732e` |
| 连接 | A/B 各 500，合计 1000/1000 READY |
| 发送 | 10000/10000 获得 ACK |
| 实时到达 | 10000/10000，到达率 100% |
| 历史落库 | 10000/10000，落库率 100% |
| 异常 | 丢失 0、重复 0、乱序 0、断连 0、发送错误 0 |
| ACK 延迟 | P50 约 650ms，P95 1313ms，最大 2075ms |
| 同机 echo 投递 P95 | 2s 直方图桶 |
| 报告门禁 | 正确性通过；延迟门禁未通过 |

本轮中 A/B 时钟未对齐，A 端记录到 4334 个跨机器负延迟样本，因此不使用跨机器单向延迟作为结论；延迟门禁使用发送机本机 ACK 和 echo 口径。

### 3.1 服务端阶段耗时

| 阶段 | 平均耗时 | P95 所在桶 |
|---|---:|---:|
| `relationship_check` | 66.9ms | 250ms |
| `redis_idempotency` | 21.1ms | 100ms |
| `redis_sequence` | 62.7ms | 250ms |
| `kafka_produce` | 11.0ms | 25ms |
| `save` | 116.9ms | 500ms |

`meeting_im` 和 `hotgo` 连接池在该轮起压窗口的等待次数和等待时间增量均为 0，未出现连接池枯竭。

### 3.2 Kafka 和落库

- `im-server.message_persist` 的 consumer lag 峰值为 4663。
- lag 在发压结束后约 2 分钟清零。
- 测试窗口中批量持久化的单批平均耗时约 3.52s，P95 落在 10s 直方图桶。
- agent 在等待 Kafka 追平后回查历史，10000 条 ACK 消息全部找到，没有持久化丢失。

结论是当前系统能在突发后最终消化积压，但前台 ACK 和异步落库延迟仍高，这两项应单独作为后续优化指标。

## 4. 历史机器 B 运行文件

以下为首轮历史运行包，不能继续用于新轮次：

```text
/tmp/allrich-machine-b-runtime-p2p-20260927-01.zip
SHA-256: 479f119e7d01e1829c7262cace282c72a5f53ad8e7f5128abc2ade75d046db64
```

机器 B 必须先安全获取该文件，再执行：

```bash
git switch dev
git pull --ff-only origin dev

# 运行包不在 Git 中，必须从机器 A 单独复制
scp youshunlai@192.168.1.135:/tmp/allrich-machine-b-runtime-p2p-20260927-01.zip /tmp/
shasum -a 256 /tmp/allrich-machine-b-runtime-p2p-20260927-01.zip

unzip -o /tmp/allrich-machine-b-runtime-p2p-20260927-01.zip \
  -d loadtest/im-pressure
chmod 600 loadtest/im-pressure/.env.test \
  loadtest/im-pressure/config.json \
  loadtest/im-pressure/manifest.json

set -a
source loadtest/im-pressure/.env.test
set +a
cd loadtest/im-pressure
go build -o im-pressure .

./im-pressure agent \
  -config config.json \
  -manifest manifest.json \
  -machine b \
  -coordinator http://192.168.1.135:8090 \
  -metrics-listen :9105 \
  -output results/p2p-20260927-01/agent-b-summary.json
```

完整 B 机操作和故障处理见 [`loadtest/im-pressure/MACHINE-B.md`](../../loadtest/im-pressure/MACHINE-B.md)。

## 5. 多 Pod 口径说明

当前 A/B 配置均使用 `wss://api.118im.com/v0/channels` 公共入口。该配置验证 LB 实际分配下的多 Pod 能力，但不能保证两台压测机固定落到不同 Pod。若验收要求强制指定不同 Pod，需要提供两个独立 WS 定向入口，分别配置到 `endpoints.a` 和 `endpoints.b`。

## 6. 后续测试顺序

### 6.1 P0：扩容到 2000 个用户

1. 将机器 A 的 `config.json` 修改为 `users_per_machine=1000`。
2. 机器 A 执行 `prepare` 和 `verify`，确认 2000 账号、1000 对好友、1000 个 P2P Topic 和 2000 人群都就绪。
3. 重新生成包含 `.env.test`、`config.json`、`manifest.json` 的 B 机运行包，B 机解压后执行 `verify`。
4. A/B 都执行 NTP 校时，要求偏差小于 50ms，否则继续忽略跨机器单向延迟。

### 6.2 P1：2000 人群聊

使用 `scenario=group`：

- A/B 各建立 1000 个 WS，合计 2000 个在线群成员。
- A/B 各取前 500 个发送者，每人 2 条，合计 2000 条群消息。
- A/B 交错每 100ms 发送 1 条，单轮发送窗口约 100s。
- 期望实时投递为 2000 条消息 x 2000 连接，即 400 万次有效到达。
- 检查群消息 ACK、每个 WS 的到达数、重复、乱序、断连、`im.group.message.persist` lag 和群消息月表落库。

群聊是下一个应执行的场景，因为它直接验证本次多 Pod 改造的 Redis fanout 和群消息 Kafka 持久化。

### 6.3 P2：混合场景

群聊正确性通过后使用 `scenario=mixed`：

- 300 对私聊用户双向各发 5 条，合计 3000 条私聊消息。
- A/B 各 250 个群发送者，每人 2 条，合计 1000 条群消息。
- 同时观察私聊与群聊的到达率、两个 Kafka 持久化 Topic 的 lag，以及 Redis、MySQL 和 3 个 Pod 的资源争用。

### 6.4 P3：单聊完整规模回归

最后在 2000 连接下重跑 `p2p`，即 1000 对用户双向各发 10 条，共 20000 条。延迟门禁仍为 ACK P95 <= 500ms、同机 echo P95 <= 1000ms；若只有正确性通过而延迟未通过，结论必须标记为“可靠性通过，性能未达标”。