# IM 双机压力测试工具

该工具按商户 `006` 的固定模型运行：两台压测机各承载 1000 个 WebSocket 用户，共 2000 个用户、1000 对好友和一个 2000 人群。

## 统计口径

- 发送成功以 `{ctrl code=2xx, params.seq>0}` 为准，形成两台机器共享的 ACK 台账。
- 实时到达只统计同时匹配本轮 `run_id` 和 `x-im-client-mid` 的 `{data}`。
- 群消息设置 `noecho=false`，每条服务端接受的群消息期望 2000 个连接各收到一次。
- 实时 drain 结束后通过 `{get what=data}` 按 ACK 的 Topic/Seq 回查历史，区分跨 Pod 实时漏投与数据库持久化缺失。
- `manifest.json` 含登录 token，文件权限为 `0600`，不得提交到 Git 或放入结果包。

## 构建与配置

两台机器使用同一版本二进制、配置和 manifest：

```bash
go build -o loadtest/im-pressure/im-pressure ./loadtest/im-pressure
cp loadtest/im-pressure/config.example.json loadtest/im-pressure/config.json
export IM_API_KEY='...'
export IM_LOAD_PASSWORD='...'
```

修改 `config.json`：`http_base` 指向 IM HTTP API；`endpoints.a/b` 分别填写两台机器应直连的 WS Pod/LB 地址，多个地址时用户会轮询分配。正式测试保持 `insecure_tls=false`。

## 一次性准备

只在一台机器执行。命令可重复运行，会复用已有账号、好友和群：

```bash
./loadtest/im-pressure/im-pressure prepare \
  -config loadtest/im-pressure/config.json \
  -manifest loadtest/im-pressure/manifest.json

./loadtest/im-pressure/im-pressure verify \
  -config loadtest/im-pressure/config.json \
  -manifest loadtest/im-pressure/manifest.json
```

将 `config.json` 和 `manifest.json` 安全复制到机器 B，并执行 `chmod 600 loadtest/im-pressure/manifest.json`。

## 双机运行

先在机器 A 启动协调器。`run-id` 每轮必须唯一且不超过 24 个字符：

```bash
mkdir -p loadtest/im-pressure/results/p2p-001
./loadtest/im-pressure/im-pressure coordinator \
  -listen :8090 -run-id p2p-001 -scenario p2p \
  -output loadtest/im-pressure/results/p2p-001/coordinator.json
```

然后分别启动两个 agent。`COORDINATOR_IP` 必须是机器 B 可访问的机器 A 内网地址。

机器 A：

```bash
./loadtest/im-pressure/im-pressure agent \
  -config loadtest/im-pressure/config.json \
  -manifest loadtest/im-pressure/manifest.json \
  -machine a -coordinator http://COORDINATOR_IP:8090 \
  -metrics-listen :9105 \
  -output loadtest/im-pressure/results/p2p-001/agent-a-summary.json
```

机器 B：

```bash
./loadtest/im-pressure/im-pressure agent \
  -config loadtest/im-pressure/config.json \
  -manifest loadtest/im-pressure/manifest.json \
  -machine b -coordinator http://COORDINATOR_IP:8090 \
  -metrics-listen :9105 \
  -output loadtest/im-pressure/results/p2p-001/agent-b-summary.json
```

两个 agent 都建立 1000 条连接后，协调器下发统一的 UTC `start_at`。场景可替换为：

- `p2p`：1000 对用户两侧同时发送，默认每人 10 条、间隔 1 秒。
- `group`：每台机器 500 个发送者，每人 2 条；全局每 100ms 一条，共 2000 条。
- `mixed`：300 对私聊用户每人 5 条，同时每台 250 个群发送者各发 2 条。

## 合并报告

把两个 agent summary 放到同一台机器：

```bash
./loadtest/im-pressure/im-pressure merge \
  -a loadtest/im-pressure/results/p2p-001/agent-a-summary.json \
  -b loadtest/im-pressure/results/p2p-001/agent-b-summary.json \
  -output loadtest/im-pressure/results/p2p-001/report.json
```

`report.json` 给出 ACK、实时投递、重复、乱序、断连和历史持久化核验结果。当前正确性门禁要求上述错误计数全部为 0。

每个 agent 在 `:9105/metrics` 暴露连接、发送、接收、重复、乱序、断连以及 Go/process 指标；端口冲突时可通过 `-metrics-listen` 修改，传空字符串可关闭。

## 指标采集

`collect` 可并行抓取 Prometheus、Redis exporter、Kafka exporter、mysqld exporter、kube-state-metrics/cAdvisor 和压测机 node-exporter，原始响应按时间写入 JSONL：

```bash
./loadtest/im-pressure/im-pressure collect \
  -duration 10m -interval 5s \
  -url im=http://PROMETHEUS_HOST/api/v1/query?query=up \
  -url redis=http://REDIS_EXPORTER/metrics \
  -url kafka=http://KAFKA_EXPORTER/metrics \
  -url mysql=http://MYSQLD_EXPORTER/metrics \
  -url node-a=http://NODE_A_EXPORTER/metrics \
  -url node-b=http://NODE_B_EXPORTER/metrics \
  -output loadtest/im-pressure/results/p2p-001/metrics.jsonl
```

URL 含 `&` 时需用单引号包住整个 `name=url` 参数。建议起压前 2 分钟开始采集，结束后继续 5 分钟，以观察 Kafka lag、数据库落库追平时间及资源恢复。

## 运行前检查

```bash
ulimit -n 100000
curl -fsS http://COORDINATOR_IP:8090/v1/status
```

两台压测机应完成时钟同步，并确认压测出口、Ingress、Pod 与 Redis/MySQL/Kafka 连接数限制可以容纳本轮负载。协调器没有鉴权，只能监听在受控压测网络中。