利用 Ubuntu 上的 JS 日志进行性能基准测试
一 目标与总体流程
- 明确可量化指标：以日志中的响应时间 P50/P95/P99、吞吐 RPS、错误率、峰值内存 RSS为核心指标，形成可回归的基准线。
- 固化采集方式：在应用内统一输出结构化日志（如 JSON），记录method、url、status、duration、route、pid、ts等字段，便于后续统计与对比。
- 生成稳定负载：使用Autocannon、k6、Artillery、wrk等在目标环境产生可重复的并发请求，覆盖常规性能与压力场景。
- 运行与记录：每次测试固定时长/请求总量，将应用日志与负载工具输出分别落盘，确保时钟同步（建议 NTP）。
- 统计与对比：用命令行或分析器对日志做分位数与吞吐计算，输出报告并与历史基准对比，判定是否回归或优化生效。
二 日志埋点与输出规范
- 结构化中间件示例（Node.js + Express）：使用morgan记录请求耗时，并输出 JSON 便于分析；同时可在响应 finish 时补充自定义字段。
- 高精度计时：在关键路径使用**process.hrtime.bigint()**获取纳秒级耗时，避免 Date.now() 的毫秒精度限制。
- 资源监控：定时打点process.memoryUsage()（如 RSS、HeapUsed），与请求日志关联，观察负载下的内存变化。
- 日志落地与轮转：使用winston/pino写入文件，配合logrotate按日轮转并压缩，防止磁盘被压满影响测试。
- 示例代码片段（要点）：
- morgan.token(‘response-time-ms’, (req, res) =>
${(res.getHeader('X-Response-Time') || 0).toFixed(3)});
- 中间件记录 start、end、duration，res.on(‘finish’) 输出 JSON；
- setInterval 每 1s 记录 memoryUsage 到日志。
三 生成负载与稳定复现
- 选择工具与场景：
- Autocannon：Node.js 生态，HTTP/1.1，统计友好，适合 API 基准与回归。
- k6：脚本化（JS）、CI/CD 友好、指标丰富，适合复杂流程与阈值门禁。
- Artillery：YAML/JS 场景编排，支持 HTTP、WebSocket、Socket.IO、gRPC 等。
- wrk/wrk2：系统级高并发，适合极限压测与长稳压测。
- 示例命令（请根据目标地址与端口调整）：
- Autocannon：autocannon -c 100 -d 30 http://localhost:3000
- k6：k6 run --vus 100 --duration 30s script.js
- Artillery：artillery run -c 50 -d 30 scripts/load.yml
- wrk：wrk -t12 -c400 -d30s http://localhost:3000
- 复现要点：固定并发数/连接数、持续时间、请求分布（权重/链路）、预热时间，并在同一台机器或同规格环境下执行，减少环境噪声。
四 从日志计算基准指标
- 字段约定：假设日志为 JSON 行，包含ts（ISO8601 或毫秒时间戳）、method、url、status、route、duration（ms）。
- 统计思路：
- 过滤有效请求（如 2xx/3xx），按route 或 endpoint分组；
- 计算P50/P95/P99、平均响应时间、RPS=请求数/测试时长、错误率=失败数/总数；
- 关联内存日志，取测试窗口内的RSS 最大值与均值。
- 命令行快速分析示例（假设日志为 JSON，每行含 duration、status、ts）：
- 基本计数与 RPS：
- 总请求数：wc -l access.log
- RPS：echo “scale=2; $(wc -l < access.log) / 30” | bc
- P50/P95/P99（毫秒，假设 duration 为 ms）：
- sort -n -k1 access.log | awk ‘{durations[NR]=$1} END {n=NR; q=0.5; print “P50:”, durations[int(nq+0.5)]; q=0.95; print “P95:”, durations[int(nq+0.5)]; q=0.99; print “P99:”, durations[int(n*q+0.5)]}’
- 错误率与按路由分位数：
- 错误率：awk ‘$2 ~ /^[45]/ {err++; total++} END {print “ErrorRate:”, err/total}’ access.log
- 按路由 P95（假设第 3 列为 route，第 1 列为 duration）：
- awk ‘{d[$3]=d[$3] (d[$3]?" “:”“) $1} END {for (r in d) {n=split(d[r],a,” "); asort(a); q=0.95; print r, “P95:”, a[int(n*q+0.5)]}}’ access.log
- 内存峰值（假设日志含 rss 字段，单位 KB）：
- awk ‘$1==“MEM” {if($2>peak) peak=$2} END {print “PeakRSS(KB):”, peak}’ mem.log
- 可视化与持续化：将统计结果写入CSV/JSON，用 Grafana/Prometheus 或 ELK 做趋势对比，形成版本-场景-指标的基准看板。
五 判定与优化闭环
- 判定规则：对比当前与历史基准，关注P95/P99 是否上升、RPS 是否下降、错误率是否升高；若任一核心指标超出阈值，即视为性能退化。
- 深入定位：
- CPU/事件循环：使用Node.js --inspect 结合 Chrome DevTools Performance 做火焰图；或用 node --prof / --prof-process 分析 V8 热点。
- 系统层面：top/htop、perf、strace 辅助排查系统调用与资源竞争。
- 内存与泄漏：process.memoryUsage() 趋势、–inspect 堆快照、必要时配合 Heapdump。
- 优化与回归：针对热点路径做异步化、缓存、数据库索引/慢查询优化、连接池与流处理等；再次运行相同负载与日志统计，验证P50/P95/P99 与 RPS是否回到或优于基准线。
