feat：新增请求性能数据记录

[ding113]

如首字节时间、每秒输出 token 数（请求耗时-首字节时间作为输出用时，该请求输出 token 除以输出用时）

请求性能数据记录于现有 log 表中，持久化存储于数据库。并在请求详情弹框中单独开辟区域精简显示。

并在排行榜中新增供应商排行榜部分，新增首字节时间、每秒输出 token 数两列统计口径。删除请求耗时列。（因为无意义）

需要确认：如何确定首字节时间（比如应该为流式输出收到第一个块的时间，不管是不是 message 块）

[github-actions]

感谢提交这个功能建议！

分析结果

根据对代码库的分析，实现此功能涉及以下关键部分：

1. 数据库 Schema 更新

现有 message_request 表（src/drizzle/schema.ts 第 255-335 行）已记录以下字段：

• durationMs - 请求总耗时
• inputTokens / outputTokens - Token 使用量
• providerId - 供应商 ID

需要新增字段：

• timeToFirstByte (integer) - 首字节时间（毫秒）

每秒输出 Token 数可以根据现有数据计算：outputTokens / ((durationMs - timeToFirstByte) / 1000)，无需额外存储。

2. 首字节时间测量点

根据 src/app/v1/_lib/proxy/response-handler.ts 的分析：

流式响应（第 761-987 行）：

• 代码已使用 isFirstChunk 标记来清除响应超时定时器（第 974-987 行）
• 首字节时间应在此处记录：Date.now() - session.startTime

非流式响应：

• 首字节时间等于响应体读取完成时间（因为非流式是整体返回）

关于您的确认问题：对于流式输出，"首字节时间"应为收到第一个数据块的时间，不论块内容类型（这与现有 isFirstChunk 逻辑一致）。

3. 供应商排行榜更新

现有供应商排行榜（src/repository/leaderboard.ts 第 24-32 行）包含：

• totalRequests - 总请求数
• totalCost - 总成本
• successRate - 成功率
• avgResponseTime - 平均响应时间

需要调整：

• 新增 avgTimeToFirstByte - 平均首字节时间
• 新增 avgTokensPerSecond - 平均每秒输出 Token 数
• 关于"删除请求耗时列"的建议：avgResponseTime 可考虑替换为新指标，但保留与否需要权衡（某些场景下总耗时仍有参考价值）

4. 实现要点

1. 数据库迁移：新增 time_to_first_byte 列
2. Session 扩展：在 ProxySession 中添加首字节时间记录方法
3. 响应处理：在 handleStream 中检测到 isFirstChunk 时记录 TTFB
4. 数据持久化：更新 updateMessageRequestDetails 调用以包含 TTFB
5. 排行榜查询：扩展 findProviderLeaderboardWithTimezone SQL 计算新指标
6. 前端展示：更新请求详情弹框和排行榜组件

---

Automated response from Claude AI

[github-actions]

Thank you for this feature suggestion.

Feasibility assessment

• Requests are already logged to the message_request table with duration_ms, input_tokens, output_tokens, etc. (src/drizzle/schema.ts L255-L295). The proxy pipeline creates a row at request start and updates duration/tokens when the response completes, so adding per-request performance fields can follow the same pattern.

Relevant existing code (verified)

• Create log row: src/app/v1/_lib/proxy/message-service.ts L34-L54 (createMessageRequest(...)).
• Streaming completion persists duration + tokens: src/app/v1/_lib/proxy/response-handler.ts L848-L851 and L927-L940.
• Streaming “first byte” is currently treated as the first received stream chunk (not SSE event-type specific); the first-byte timeout is cleared on that first chunk: src/app/v1/_lib/proxy/response-handler.ts L973-L987.

// src/app/v1/_lib/proxy/response-handler.ts (around L973)
if (isFirstChunk) {
  isFirstChunk = false;
  if (sessionWithCleanup.clearResponseTimeout) {
    sessionWithCleanup.clearResponseTimeout();
  }
}

• The streaming first-byte timeout is intentionally kept running after HTTP headers are received (so it’s tied to body data arrival): src/app/v1/_lib/proxy/forwarder.ts L1235-L1266 and L1376-L1386.
• Provider leaderboard currently uses avg(message_request.duration_ms) as avgResponseTime: src/repository/leaderboard.ts L292-L318, rendered in src/app/[locale]/dashboard/leaderboard/_components/leaderboard-view.tsx L203-L207.

Implementation considerations

• Baseline: durationMs is computed from ProxySession.startTime (set at request receipt; src/app/v1/_lib/proxy/session.ts L121-L123). If firstByteMs uses the same baseline, durationMs - firstByteMs is consistent with existing logs.
• Non-stream path currently uses responseForLog.text() (waits for full body), so there isn’t an existing “first chunk” hook there: src/app/v1/_lib/proxy/response-handler.ts L279-L283.
• Throughput depends on output_tokens; parsing can yield usageMetrics: null if no usage is found: src/app/v1/_lib/proxy/response-handler.ts L1338-L1423 (so derived metrics should handle nulls).

UI touchpoints

• Usage logs table shows durationMs and opens the request details dialog (ErrorDetailsDialog) per row: src/app/[locale]/dashboard/logs/_components/usage-logs-table.tsx L84-L97 and L351-L385.
• Logs rows come from message_request in src/repository/usage-logs.ts L183-L213; the dialog component is src/app/[locale]/dashboard/logs/_components/error-details-dialog.tsx (export at L61).

Question (from “需要确认”)

• For streaming requests, should 首字节时间 follow the existing behavior (time until the first stream chunk is received, regardless of chunk/event type), as implemented in src/app/v1/_lib/proxy/response-handler.ts L973-L987?

---

Automated response from Codex AI