3、延迟测量方法：时间戳打点法、perf工具使用、eBPF追踪、火焰图分析、用户态与内核态延迟区分
说到延迟测量，我见过太多人一上来就拍脑袋猜瓶颈。说实话，没有数据支撑的优化都是耍流氓。这一节，我把自己压箱底的几套测量方法全掏出来，从最原始的时间戳打点，到高大上的eBPF追踪，咱们一个一个过。
3.1 时间戳打点法：最朴素的武器
这方法听起来土，但真管用。我在早期做网关优化时，就是靠它定位到某个函数多花了200微秒。
核心思路很简单：在代码关键路径上插入时间戳，计算差值。
#include <time.h>
struct timespec ts_start, ts_end;
clock_gettime(CLOCK_MONOTONIC, &ts_start);
// 你要测量的代码段
process_packet();
clock_gettime(CLOCK_MONOTONIC, &ts_end);
double elapsed = (ts_end.tv_sec - ts_start.tv_sec) * 1e9 +
(ts_end.tv_nsec - ts_start.tv_nsec);
printf("process_packet took %.0f ns\n", elapsed);
注意：clock_gettime本身有开销，大约几十纳秒。测量微秒级以下的延迟时，这个误差不可忽略。我建议做多次测量取中位数，别被单次抖动骗了。
你想想看，如果每个关键函数都打上点，跑一遍压力测试，哪个环节慢就一目了然。不过缺点也明显——你得改代码，生产环境不一定允许。
3.2 perf工具：内核级性能剖析
perf是我日常用得最多的工具。它不需要改代码，直接采样CPU的硬件计数器，精度高得吓人。
基本用法就这几条命令，我背得滚瓜烂熟：
# 统计CPU周期和指令数
perf stat ./your_program
# 采样调用栈，生成报告
perf record -F 99 -g ./your_program
perf report
# 只看某个进程
perf top -p PID
我个人习惯先用perf stat看整体指标。如果cycles远大于instructions，说明CPU在等内存或锁，这时候就该深挖了。
小技巧：采样频率-F 99是个好选择。99Hz不会太打扰系统，又能拿到足够样本。我曾经试过1000Hz，结果程序本身被采样拖慢了30%。
3.3 eBPF追踪：动态插桩的利器
eBPF这东西，说白了就是让你在内核里安全地跑一段小程序。它可以在不重启内核、不改代码的情况下，追踪任意内核函数和用户态函数。
举个例子，我想看某个进程的accept()调用花了多久：
# 用bpftrace写一行脚本
bpftrace -e 'kprobe:sys_accept { @start[tid] = nsecs; }
kretprobe:sys_accept /@start[tid]/ {
$lat = nsecs - @start[tid];
printf("accept latency: %d us\n", $lat / 1000);
delete(@start[tid]);
}'
嗯，这里要注意：eBPF程序运行在内核上下文，不能做复杂操作。你写的代码必须通过验证器检查，循环次数、指令数都有限制。我第一次写eBPF程序时，就因为一个无限循环把内核搞挂了——还好只是开发机。
| 方法 | 开销 | 适用场景 |
|---|---|---|
| 时间戳打点 | 几十纳秒 | 开发环境，精确测量 |
| perf采样 | 极低（硬件支持） | 生产环境，宏观分析 |
| eBPF追踪 | 微秒级 | 动态调试，内核态分析 |
3.4 火焰图分析：一眼看穿热点
perf采集的数据怎么可视化？火焰图。这东西是 Brendan Gregg 发明的，我每次做性能分析都离不开它。
生成火焰图的流程我走了无数遍：
# 1. 采集数据
perf record -F 99 -g -p PID -- sleep 30
# 2. 生成火焰图
perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.svg
拿到火焰图后，我一般先看顶部最宽的色块。越宽说明CPU时间占比越高。如果某个函数占了30%以上，那它就是优化目标。
核心原则：火焰图的宽度代表CPU时间占比，不是调用次数。一个函数被调了1万次但每次很快，它在图上可能只有一条细线。别被调用次数骗了，要看总耗时。
3.5 用户态与内核态延迟区分
这是最容易被忽视的一点。很多延迟问题，其实出在内核态，但大家习惯性在用户态代码里找原因。
怎么区分？我常用的方法有两个：
- perf stat 看 sys 占比：如果
sys占比超过 20%，说明内核态开销大。这时候要查系统调用、中断、锁竞争。 - eBPF 追踪上下文切换：用
tracepoint:sched:sched_switch看进程被谁抢占了，抢了多久。
# 追踪上下文切换延迟
bpftrace -e 'tracepoint:sched:sched_switch {
$delta = nsecs - @last[tid];
if ($delta > 1000000) {
printf("PID %d was off CPU for %d us\n", tid, $delta/1000);
}
@last[next_tid] = nsecs;
}'
我曾经遇到一个诡异问题：用户态代码看起来没问题，但延迟就是高。用perf一查，发现sys占比高达40%。再深挖，原来是内核的spin_lock在争抢。换成rwlock后，延迟直接降了60%。
避坑指南：用户态和内核态的切换本身就有开销（约100-200ns）。如果业务逻辑允许，尽量用io_uring或epoll减少系统调用次数。我见过有人每个包都调一次sendto，改成批量发送后吞吐翻倍。
3.6 本章知识体系
下面这张图总结了延迟测量的核心逻辑。从数据采集到可视化，再到定位根因，每一步都有对应的工具和方法。
说白了，延迟测量没有银弹。不同场景选不同工具，关键是要理解每个工具的适用边界。时间戳打点适合精确测量，perf适合宏观分析，eBPF适合动态追踪，火焰图适合可视化。把它们组合起来用，你就能像剥洋葱一样，一层层找到延迟的根因。
公众号:蓝海资料掘金营，微信deep3321