perf-profile

/perf-profile

分析应用性能：代码执行时间、DB 调用时间，以及应用层和数据库层的瓶颈识别。

步骤 1：确定目标

询问用户（或根据上下文推断）：我们要分析什么的性能？

• 特定端点 / 路由
• 后台任务 / 工作进程
• 特定函数或模块
• 整个应用（常规审计）

步骤 2：DB 调用时间分析

PostgreSQL

# Enable timing in psql
psql "$DATABASE_URL" -c "\timing on"

# Check pg_stat_statements for query timing (if available)
psql "$DATABASE_URL" -c "
  SELECT
    LEFT(query, 80) AS query,
    calls,
    ROUND(mean_exec_time::numeric, 2) AS mean_ms,
    ROUND(total_exec_time::numeric, 2) AS total_ms,
    ROUND((total_exec_time / SUM(total_exec_time) OVER ()) * 100, 1) AS pct_total
  FROM pg_stat_statements
  ORDER BY mean_exec_time DESC
  LIMIT 20;
" 2>/dev/null || echo "pg_stat_statements not available — enable with: CREATE EXTENSION pg_stat_statements;"

MySQL / MariaDB

mysql -e "
  SELECT
    LEFT(DIGEST_TEXT, 80) AS query,
    COUNT_STAR AS calls,
    ROUND(AVG_TIMER_WAIT/1e9, 2) AS mean_ms,
    ROUND(SUM_TIMER_WAIT/1e9, 2) AS total_ms
  FROM performance_schema.events_statements_summary_by_digest
  ORDER BY AVG_TIMER_WAIT DESC
  LIMIT 20;
" 2>/dev/null || echo "MySQL performance_schema unavailable"

报告：按平均执行时间排列的前 20 条查询表格，包含调用次数和占 DB 总耗时的百分比。

步骤 3：应用级性能分析

检测运行时并推荐合适的分析器：

# Detect language/framework
[ -f package.json ] && echo "RUNTIME=node"
[ -f Gemfile ] && echo "RUNTIME=ruby"
[ -f requirements.txt ] || [ -f pyproject.toml ] && echo "RUNTIME=python"
[ -f go.mod ] && echo "RUNTIME=go"
[ -f pom.xml ] || [ -f build.gradle ] && echo "RUNTIME=java"

Node.js：

• 内置：node --prof app.js + node --prof-process isolate-*.log
• 对于 Web：添加 --inspect 并使用 Chrome DevTools 分析器
• 建议：使用 clinic.js（npx clinic doctor -- node app.js）生成火焰图

Ruby：

• 建议：Rails 使用 stackprof 或 rack-mini-profiler
• 针对特定方法：使用 Benchmark.measure { ... } 包裹

Python：

• 内置：python -m cProfile -s cumulative script.py
• 对于 Web：使用 py-spy top --pid <pid> 进行实时性能分析
• 建议：使用 snakeviz 进行可视化

Go：

• 内置：go tool pprof http://localhost:6060/debug/pprof/profile
• 添加 import _ "net/http/pprof" 以启用该端点

扫描现有的计时插桩：

grep -rn "benchmark\|timing\|elapsed\|duration\|stopwatch\|time\.now\|Time\.now\|perf_hook\|performance\.now" \
  --include="*.rb" --include="*.py" --include="*.js" --include="*.ts" --include="*.go" \
  . 2>/dev/null | head -20

步骤 4：代码级瓶颈扫描

扫描代码库中的常见性能反模式：

异步上下文中的同步阻塞：

grep -rn "fs\.readFileSync\|execSync\|spawnSync\|sleep\|time\.Sleep" \
  --include="*.js" --include="*.ts" --include="*.go" . 2>/dev/null | head -10

缺少分页（无界查询）：

grep -rn "\.all\b\|find_all\|SELECT \*\b" \
  --include="*.rb" --include="*.py" --include="*.js" --include="*.ts" . 2>/dev/null | head -10

循环中重复执行开销大的调用：

grep -rn "each\|forEach\|for " \
  --include="*.rb" --include="*.py" --include="*.js" --include="*.ts" . 2>/dev/null | head -20

对于每个标记出的文件，阅读上下文并评估影响。

步骤 5：响应时间目标

根据以下阈值评估发现的问题：

指标	良好	可接受	需要修复
DB 查询平均耗时	<10ms	<100ms	>100ms
每个请求的 DB 调用次数	≤3	≤10	>10
端点响应时间	<100ms	<500ms	>500ms
后台任务耗时	<1s	<30s	>30s

步骤 6：瓶颈报告

## Performance Profile Report

### DB Layer
- Slowest query: <query> — Xms mean (Y calls/min)
- Total DB time as % of request: Z%
- Queries over 100ms: N

### Application Layer
- Blocking calls found: X
- Unbounded queries (no LIMIT): Y
- Loops with expensive operations: Z

### Top 3 Bottlenecks (by estimated impact)
1. <bottleneck> — estimated Xms saved per request
2. <bottleneck> — estimated Yms saved per request
3. <bottleneck> — estimated Zms saved per request

### Recommended profiling tools for this stack
- <tool 1>
- <tool 2>

询问：“要我修复最严重的瓶颈，还是设置性能分析插桩，以便你测量修复前后的表现？”