[Bug]: 请求监控页 7/30 天窗口必然超时：前端未使用 compact summary / 汇总快速路径（实测 180× 差距）

[aod321]

问题类型

前端显示或交互异常

部署方式

完整 Docker 方案

CPA 版本

v7.2.67

CPA Manager Plus 版本

v1.11.4（Docker seakee/cpa-manager-plus:latest，revision 78d189e）

问题描述

请求监控页选择「最近 7 天」或「最近 30 天」时页面无限转圈，最终前端超时（REQUEST_TIMEOUT_MS = 30s），页面不可用。v1.11.4 升级后依旧。同一实例、同一数据量下「用量分析」页和「仪表盘」很快，只有请求监控页超时。

数据规模：usage_events 约 556,000 条，usage.sqlite 约 8GB。

根因定位（已读源码 + 直接压测 API）：请求监控页把所有维度塞进单个 analytics 请求，且 summary 未使用 compact profile（apps/web/src/features/monitoring/hooks/useMonitoringData.ts 约 L469）：

include: {
  summary: true,          // ← 无 summary_profile: 'compact'
  timeline: true,
  hourly_distribution: true,
  model_share: true,
  channel_share: true,
  model_stats: true,
  failure_sources: true,
  account_stats: true,
  api_key_stats: true,
  ...
}

而服务端的快速路径（compact summary、hourly rollup）已存在且工作正常——用量分析页走的就是这些路径（usageAnalyticsModel.ts 中 summary_profile: 'compact'）。

实测数据（556k 事件，7 天窗口，直接 curl POST /v0/management/monitoring/analytics）：

include	耗时
summary（完整模式，监控页现状）	7.9~8.3s
summary + summary_profile: "compact"	0.044s（约 180×）
model_stats（命中 hourly rollup）	0.04s
account_stats	3.5s
model_share + channel_share	2.9s
监控页完整 include 组合	23s

23s 已接近前端 30s 超时；页面实际会并发多个请求（analytics + header-snapshots 等），在 SQLite 连接池（max 4）上排队后单请求可达 50s+，必然超时。补充：summary_percentiles: false 不能降低完整 summary 耗时（8.3s），说明大头不在百分位，而在完整 summary 的其余全表聚合子查询。

期望方案：

• 请求监控页 summary 改用 summary_profile: 'compact'，缺失字段按需二次加载
• 各维度拆分为独立请求 / 按 Tab 懒加载（参考用量分析页 v1.11 的做法）
• analytics 优先复用 usage_dashboard_hourly_rollups（与 [Feature]: 优化请求监控存储与查询，增加历史记录清理功能 #332「优化 analytics 查询，优先使用汇总数据」一致）

关联：#332（feature，含存储清理；本 issue 是其中「analytics 查询慢」部分的具体定位，仅前端改走已有快速路径即可解决超时，不依赖存储清理）；#370（用量分析同类超时，已在 v1.11 修复；请求监控页是遗留场景）。

复现步骤

1. 实例中积累约 50 万条以上 usage_events（约 8GB usage.sqlite）
2. 打开「请求监控」页
3. 时间范围切换为「最近 7 天」或「最近 30 天」
4. 页面无限转圈，浏览器 Network 面板可见 analytics 请求超时（>30s）被 abort 后重试，循环往复
5. 对照：用 curl 直接请求 POST /v0/management/monitoring/analytics，带监控页同款 include 组合耗时约 23s；将 summary 换成 summary_profile: "compact" 后仅 0.044s

关键配置

# docker-compose（节选，脱敏）
cpa-manager:
  image: seakee/cpa-manager-plus:latest
  network_mode: host
  environment:
    HTTP_ADDR: "0.0.0.0:18317"
    USAGE_DB_PATH: "/data/usage.sqlite"
    CPA_MANAGER_DATA_KEY_PATH: "/data/data.key"
    USAGE_COLLECTOR_MODE: "auto"
    USAGE_RESP_QUEUE: "usage"
    USAGE_BATCH_SIZE: "100"
    USAGE_POLL_INTERVAL_MS: "500"
    USAGE_QUERY_LIMIT: "50000"
    CPA_UPSTREAM_URL: "http://127.0.0.1:8327"   # 本机 nginx 跳板 -> CPA :8317
# CPA 侧：usage-statistics-enabled: true
# 存储：本地 NVMe

/status 返回内容

{
    "collector": {
        "collector": "running",
        "upstream": "http://127.0.0.1:8327",
        "mode": "auto",
        "transport": "http",
        "queue": "usage",
        "lastConsumedAt": 1784703854264,
        "lastInsertedAt": 1784703854276,
        "totalInserted": 13820,
        "totalSkipped": 0,
        "deadLetters": 0
    },
    "dataMigration": {
        "name": "usage_cache_accounting_v2",
        "status": "completed",
        "lastEventId": 542245,
        "targetEventId": 542245,
        "processedRows": 542245,
        "changedRows": 542245
    },
    "dbPath": "/data/usage.sqlite",
    "deadLetters": 0,
    "events": 556065,
    "service": "cpa-manager-plus"
}

日志

# Manager Server 无报错日志；analytics 请求在服务端正常执行至完成，仅耗时超过前端超时阈值。
# 服务端请求日志示例（大数据量下监控页 analytics 的真实耗时）：
http POST /v0/management/monitoring/analytics status=200 duration=23.1s
http GET  /v0/management/monitoring/header-snapshots status=200 duration=4.7s

截图

No response

检查清单

• 我已经搜索过现有 Issues，没有找到重复问题
• 我已经确认敏感信息已经脱敏，例如 token、key、账号信息

[seakee]

数据量大确实会有查询等问题的，上面提的这些我先做一下优化。像上面提到的大数据应该算是重度使用了，后面可能会做定时归档或清理数据功能，也可能会引入 PG/MySQL 等来增强数据处理的能力，这个需要做调研一下。

[aod321]

谢谢您！