pro/im_server

Fork 0

Files

T

richjohnrambo a974572f72 test: stabilize distributed load verification

2026-09-28 09:50:33 +08:00

8.0 KiB

Raw Blame History

机器 B 压测执行手册

给机器 B 上 AI 的指令

你当前操作的是 机器 B，代码与机器 A 完全相同。你的职责只有：核验运行文件、启动 agent -machine b、观察运行状态、把结果留给机器 A。不要执行 prepare、coordinator 或 merge，不要修改账号分片。

机器 B 固定模拟 ltb0001 至 ltb1000 共 1000 个用户。测试场景和统一开始时间由机器 A 的 coordinator 下发。

当前 allrich 测试批次

以下参数适用于 2026-09-27 的 2000 人群聊压测：

参数	值
Git 分支	`dev`
最低提交	`ea8732e`
企业码	`allrich`
HTTP	`https://api.118im.com`
WebSocket	`wss://api.118im.com/v0/channels`
机器 A 内网地址	`192.168.1.135`
Coordinator	`http://192.168.1.135:8090`
Run ID	`group2k-r1-20260927-01`
场景	`group`
机器 A 状态	等待启动 coordinator 和 agent A

机器 A 已生成安全运行包：

/tmp/group2k-r1-20260927-01.zip
SHA-256: 21e65b19476e64348b9214322021d880b231de1f9c9f685ea43d0082103e9cd1

运行包文件名固定为 /tmp/<RUN_ID>.zip。它包含被 Git 忽略的密钥和 Token，因此 git pull 不会下载该文件，必须从机器 A 的 /tmp 目录单独复制。

运行包内只有三个运行时文件：.env.test、config.json、manifest.json。其中包含 API Key、测试账号密码、固定测试验证码和账号 Token，不进入 Git，必须通过受控内网传输。测试环境验证码为 123456，正式环境禁止使用固定验证码。

因此，机器 B 只执行 git pull 后看不到这三个文件是正常现象。机器 B 需要从机器 A 单独复制运行包：

scp youshunlai@192.168.1.135:/tmp/group2k-r1-20260927-01.zip /tmp/

shasum -a 256 /tmp/group2k-r1-20260927-01.zip
# 必须输出：21e65b19476e64348b9214322021d880b231de1f9c9f685ea43d0082103e9cd1

如果机器 B 无法主动连接 A，也可以由机器 A 执行 scp 推送；目标机器的用户名和地址由 B 机提供。禁止通过 Git、公开网盘或无访问控制的 HTTP 服务传输该运行包。

本轮 A/B 都通过同一个公共 WebSocket LB 接入。它能覆盖负载均衡后的多 Pod 投递，但不能保证 A、B 被固定分配到不同 Pod；需要强制跨指定 Pod 时，应另行提供两个定向 WS 入口并更新 config.json。

运行前向机器 A 获取

开始前必须拿到以下信息：

MACHINE_A_IP：机器 A 的内网 IP。
RUN_ID：本轮唯一标识，例如 p2p-20260927-01。
config.json：两台机器使用同一份配置。
manifest.json：由机器 A 执行 prepare 生成，包含账号 Token 和 Topic。
IM_API_KEY、IM_LOAD_PASSWORD：通过安全方式提供，不写进代码或结果文件。
机器 A 已启动 coordinator 的确认。

同一份代码不代表运行时 manifest 会自动同步。如果本机没有最新的 manifest.json，必须让机器 A 传过来；机器 B 不得自行执行 prepare。

第一步：进入仓库并构建

把 /absolute/path/to/im_server 换成本机仓库绝对路径：

cd /absolute/path/to/im_server
git rev-parse HEAD
go build -o loadtest/im-pressure/im-pressure ./loadtest/im-pressure
ulimit -n 100000

将 git rev-parse HEAD 的结果发给机器 A，确认两边代码版本一致。

第二步：解压运行文件

在机器 B 的仓库根目录执行：

unzip -o /tmp/group2k-r1-20260927-01.zip \
  -d loadtest/im-pressure
chmod 600 \
  loadtest/im-pressure/.env.test \
  loadtest/im-pressure/config.json \
  loadtest/im-pressure/manifest.json

解压后必须存在：

loadtest/im-pressure/.env.test
loadtest/im-pressure/config.json
loadtest/im-pressure/manifest.json

检查文件：

test -s loadtest/im-pressure/.env.test
test -s loadtest/im-pressure/config.json
test -s loadtest/im-pressure/manifest.json

第三步：设置环境变量并核验

set -a
source loadtest/im-pressure/.env.test
set +a

export MACHINE_A_IP='192.168.1.135'
export RUN_ID='group2k-r1-20260927-01'

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

verify 必须成功后才能继续。它只读核验 2000 个账号、P2P Topic 和 2000 人群，不会开始压测。

第四步：检查机器 A 协调器

curl -fsS "http://${MACHINE_A_IP}:8090/v1/status"

如果连接失败，停止操作并让机器 A 检查 coordinator、内网 IP、防火墙和 8090 端口。不要改为本机启动 coordinator。

第五步：启动机器 B agent

mkdir -p "loadtest/im-pressure/results/${RUN_ID}"

./loadtest/im-pressure/im-pressure agent \
  -config loadtest/im-pressure/config.json \
  -manifest loadtest/im-pressure/manifest.json \
  -machine b \
  -coordinator "http://${MACHINE_A_IP}:8090" \
  -metrics-listen :9105 \
  -output "loadtest/im-pressure/results/${RUN_ID}/agent-b-summary.json"

启动后会依次发生：

机器 B 建立 1000 条 WebSocket 连接并订阅对应 P2P Topic 和群 Topic。
agent 向机器 A coordinator 报告 READY。
如果机器 A 尚未 READY，当前命令会等待，这是正常现象。
等待期间连接断开会自动重连并重新订阅；在 A/B 都实时保持 1000 条连接并完成最终屏障前，agent 不会退出或开始发压。
coordinator 下发 run_id、场景和统一 UTC 开始时间。
agent 完成发送和 WS 到达统计后，先向协调器提交未 ACK 但已观测的消息台账；等待 history_settle（默认 5 分钟）后，以同 Topic 串行、不同 Topic 并行的限速分页方式执行历史持久化回查。等待期间不要停止进程。
两机历史回查完成后会通过 coordinator 汇总命中消息，B 也会据此计算 realtime_lost_but_persisted；随后 agent 在默认 10 秒窗口内渐进关闭连接、写出 summary 并正常退出。

机器 B 不需要传场景参数。p2p、group 或 mixed 由机器 A coordinator 决定。

第六步：检查并回传结果

test -s "loadtest/im-pressure/results/${RUN_ID}/agent-b-summary.json"

将以下文件路径和运行是否成功告知机器 A：

loadtest/im-pressure/results/<RUN_ID>/agent-b-summary.json

如果机器 A 无法直接读取机器 B 文件，由机器 A 使用 scp 拉取，或从机器 B 推送：

scp "loadtest/im-pressure/results/${RUN_ID}/agent-b-summary.json" \
  user@机器A内网IP:/absolute/path/to/im_server/loadtest/im-pressure/results/${RUN_ID}/

运行中观察

另开一个终端可以查看本机 agent 指标：

curl -fsS http://127.0.0.1:9105/metrics | \
  grep -E 'im_load_agent_(ready_connections|publish|received|duplicates|out_of_order|disconnects)'

关键判断：

im_load_agent_ready_connections 应到达 1000。
disconnects_total、duplicates_total、out_of_order_total 期望为 0。
agent 进程退出前不要关闭终端或停止网络。

常见问题

coordinator connection refused：机器 A coordinator 未启动、IP 错误或 8090 被拦截。
一直等待开始：通常是另一台 agent 尚未达到 1000 个 READY，查看机器 A coordinator 状态。
登录返回 401：确认本机设置了正确的 IM_LOAD_PASSWORD，并让机器 A 重新同步最新 manifest。
listen :9105 address already in use：换成空闲端口，例如 -metrics-listen :9106，并通知机器 A 修改采集地址。
ready connections 不足 1000：不要继续压测，检查 WS 地址、文件描述符限制、Ingress 和网络连接限制。
verify 失败：停止，不要绕过；让机器 A 核对数据准备结果和本机运行文件版本。

机器 B 禁止事项

禁止运行 prepare，避免重复创建或改变测试数据。
禁止运行 coordinator，全场只能使用机器 A 的 coordinator。
禁止把参数改成 -machine a。
禁止自行改变 RUN_ID、config 或 manifest。
禁止提交或传播包含 Token 的 manifest。

8.0 KiB Raw Blame History