207 lines
6.9 KiB
Markdown
207 lines
6.9 KiB
Markdown
# 远端作品列表压测排查报告
|
||
|
||
时间：2026-05-12 06:16 CST
|
||
目标：`http://82.157.175.59`
|
||
SSH：远端生产机 root 账号（具体私钥路径仅保留在本机环境，不写入仓库）
|
||
|
||
## 背景
|
||
|
||
远端 `k6-works-list.js` 压测中：
|
||
|
||
- smoke 通过。
|
||
- baseline 10 VU：无 HTTP 错误，但 p95/p99 超阈值。
|
||
- 50 RPS spike：`http_req_failed` / `works_list_shape_error_rate` 约 21.99%。
|
||
- 100 RPS spike：`http_req_failed` / `works_list_shape_error_rate` 约 25.47%。
|
||
- 从 k6 check 看，失败主要集中在 `puzzle_gallery_list`，`custom_world_gallery_list` 基本正常。
|
||
|
||
## 已完成排查
|
||
|
||
### 1. 服务器进程与资源
|
||
|
||
远端服务监听：
|
||
|
||
- Rust api-server：`127.0.0.1:8082`，systemd 服务 `genarrative-api.service`。
|
||
- SpacetimeDB：`127.0.0.1:3101`，systemd 服务 `spacetimedb.service`。
|
||
- Nginx：公网 80 反代 `/api/*` 到 `127.0.0.1:8082`。
|
||
|
||
服务器规格/状态：
|
||
|
||
- 2 vCPU。
|
||
- 内存约 1.9GiB。
|
||
- Swap 约 1.9GiB，已有约 600MiB 使用。
|
||
- `/` 磁盘约 69%。
|
||
- Rust api-server 当前 CPU 不高。
|
||
- SpacetimeDB 当前 CPU 不高。
|
||
|
||
发现一个独立异常：
|
||
|
||
- PM2 下旧 `server-node` 进程 `genarrative` 正在重启风暴。
|
||
- cwd：`/work/Genarrative/server-node`
|
||
- 错误：连接 `127.0.0.1:5432` PostgreSQL 被拒绝。
|
||
- PM2 restart 次数已超过 33 万。
|
||
- 该进程不是当前公网 `/api/*` 使用的 Rust api-server，但会制造额外 CPU/内存/日志抖动。
|
||
|
||
### 2. 压测窗口服务端日志
|
||
|
||
子任务聚合了 2026-05-12 04:50-05:05 的 nginx 与 api-server 日志。
|
||
|
||
nginx access：
|
||
|
||
- `/api/runtime/puzzle/gallery`：4661 次，全部 200。
|
||
- `/api/runtime/custom-world-gallery`：4659 次，全部 200。
|
||
|
||
api-server journal：
|
||
|
||
`/api/runtime/puzzle/gallery`：
|
||
|
||
- completed：4661
|
||
- status：200 全部
|
||
- slow_request：0
|
||
- latency_ms：min 13 / p50 30 / p90 43 / p95 50 / p99 62 / max 88
|
||
|
||
`/api/runtime/custom-world-gallery`：
|
||
|
||
- completed：4659
|
||
- status：200 全部
|
||
- slow_request：0
|
||
- latency_ms：min 0 / p50 1 / p90 5 / p95 7 / p99 13 / max 49
|
||
|
||
结论：
|
||
|
||
- 在服务端视角，两个接口在该窗口都没有 5xx，也没有慢请求。
|
||
- 这与 k6 客户端侧 30s timeout / failed check 存在明显不一致。
|
||
- 需要进一步区分：客户端侧网络/连接耗尽/本机 k6 执行环境问题，还是 k6 统计混合/响应解析问题。
|
||
|
||
### 3. k6 脚本行为
|
||
|
||
文件：`scripts/loadtest/k6-works-list.js`
|
||
|
||
无 `AUTH_TOKEN` 时，每轮 iteration 顺序请求两个接口：
|
||
|
||
1. `GET /api/runtime/puzzle/gallery`
|
||
2. `GET /api/runtime/custom-world-gallery`
|
||
|
||
`DETAIL_RATIO=0` 时不会请求详情。
|
||
|
||
`works_list_shape_error_rate` 不只代表字段结构错误，只要下面任意 check 失败都会计入：
|
||
|
||
- status is 200
|
||
- returns json object
|
||
- has collection
|
||
- list item shape
|
||
|
||
因此 timeout、非 JSON、非 200、响应结构不符合都会表现为 shape error。
|
||
|
||
数据文件实际路径：
|
||
|
||
- `scripts/loadtest/data/works-list.local.json`
|
||
|
||
脚本里 `data/works-list.local.json` 是相对 k6 脚本文件解析的，因此本身合理。
|
||
|
||
### 4. 代码层疑似瓶颈
|
||
|
||
虽然这次远端服务端日志没有复现慢请求，但代码层仍发现一个真实性能隐患。
|
||
|
||
`/api/runtime/puzzle/gallery` 调用链：
|
||
|
||
- `server-rs/crates/api-server/src/app.rs:1192`
|
||
- `server-rs/crates/api-server/src/puzzle.rs:1385-1409`
|
||
- `server-rs/crates/spacetime-client/src/puzzle.rs:367-381`
|
||
- `server-rs/crates/spacetime-module/src/puzzle.rs:430-443`
|
||
- `server-rs/crates/spacetime-module/src/puzzle.rs:1393-1404`
|
||
|
||
关键实现：
|
||
|
||
- `list_puzzle_gallery_tx` 对 `puzzle_work_profile().iter()` 全表扫描。
|
||
- 再过滤 `publication_status == Published`。
|
||
- 对每个公开作品调用 `build_puzzle_work_profile_from_row_with_recent_count`。
|
||
- 该函数调用 `count_recent_public_work_plays(ctx, "puzzle", &row.profile_id, now_micros)`。
|
||
|
||
`count_recent_public_work_plays`：
|
||
|
||
- 文件：`server-rs/crates/spacetime-module/src/runtime/profile.rs:1296-1321`
|
||
- 当前实现对 `public_work_play_daily_stat().iter()` 全表扫描过滤。
|
||
- 但表定义已有复合索引：
|
||
- `server-rs/crates/spacetime-module/src/runtime/profile.rs:242-248`
|
||
- `by_public_work_play_daily_stat_work_day(source_type, profile_id, played_day)`
|
||
- 当前统计函数未使用该索引。
|
||
|
||
复杂度风险：
|
||
|
||
```text
|
||
puzzle gallery ~= O(puzzle_work_profile 全表扫描 + Published作品数 * public_work_play_daily_stat 全表扫描)
|
||
```
|
||
|
||
`custom-world-gallery` 与 puzzle 的差异：
|
||
|
||
- custom-world 使用 `CustomWorldGalleryEntry` 公开读模型表。
|
||
- puzzle 直接从 `puzzle_work_profile` 即席拼装。
|
||
- 两者都调用 recent count，但 puzzle 更容易受作品表规模和统计表规模影响。
|
||
|
||
## 当前判断
|
||
|
||
本次排查有两个层面的结论：
|
||
|
||
1. 生产服务端日志没有证明 `puzzle/gallery` 在 04:50-05:05 窗口真的 30s 慢或 5xx。
|
||
- api-server 记录的 p95 只有 50ms。
|
||
- nginx 看到两个接口都是 200。
|
||
- 所以 k6 侧的 30s timeout 需要进一步从客户端网络、连接池、Windows/k6 执行环境、summary 混合统计角度验证。
|
||
|
||
2. 代码层确实存在可修的性能隐患。
|
||
- `count_recent_public_work_plays` 未使用已有索引。
|
||
- puzzle gallery 对每个作品重复做 recent count。
|
||
- puzzle gallery 未使用 `publication_status` 索引或读模型。
|
||
|
||
## 建议下一步
|
||
|
||
### A. 先处理服务器 PM2 重启风暴
|
||
|
||
建议确认旧 Node 服务是否仍需要。
|
||
|
||
如果不需要，应停止并禁用 PM2 中的旧 `server-node`：
|
||
|
||
```bash
|
||
PM2_HOME=/home/ubuntu/.pm2 pm2 stop genarrative
|
||
PM2_HOME=/home/ubuntu/.pm2 pm2 delete genarrative
|
||
PM2_HOME=/home/ubuntu/.pm2 pm2 save
|
||
```
|
||
|
||
这是生产侧操作，执行前需要确认。
|
||
|
||
### B. 单接口短压验证客户端/服务端不一致
|
||
|
||
不要继续用混合脚本大压。
|
||
|
||
建议新增或临时使用单接口 k6 脚本，分别只测：
|
||
|
||
- `/api/runtime/puzzle/gallery`
|
||
- `/api/runtime/custom-world-gallery`
|
||
|
||
并在同一时间窗口并行采集：
|
||
|
||
- k6 客户端 summary
|
||
- nginx access 请求数/状态码
|
||
- api-server journal latency
|
||
- 本机到服务器网络错误/timeout
|
||
|
||
目标是确认 timeout 是不是发生在客户端侧连接/网络，而不是服务端处理慢。
|
||
|
||
### C. 修复代码性能隐患
|
||
|
||
优先级建议：
|
||
|
||
1. `count_recent_public_work_plays` 改为使用 `by_public_work_play_daily_stat_work_day` 复合索引，或至少改成批量统计，避免 N 次全表扫描。
|
||
2. `list_puzzle_gallery_tx` 使用 `by_puzzle_work_publication_status` 索引查询 Published，或参考 custom-world 建立 `puzzle_gallery_entry` 公开读模型。
|
||
3. gallery 列表页不要实时逐条扫描统计表，可维护读模型或批量聚合 `recent_play_count_7d`。
|
||
|
||
### D. 调整 k6 脚本输出
|
||
|
||
建议 k6 summary 按 endpoint tag 输出或新增单接口模式，否则 overall 指标会把 puzzle/custom-world 混在一起。
|
||
|
||
建议增加：
|
||
|
||
- `ENDPOINT=puzzle_gallery_list`
|
||
- `ENDPOINT=custom_world_gallery_list`
|
||
|
||
让脚本只跑一个 endpoint，避免诊断时混淆。
|