考虑延迟，最好考虑最大延迟即同步或阻塞操作下的延迟。像非阻塞 I/O + I/O
多路复用等异步的，测量吞吐量或iops倒是可以。如你所说，应该插装代码或在各阶段systemtap统计非阻塞 I/O + I/O
多路复用情况下所带来的延时。
谢谢你的分享。
On 8/27/13, Yichun Zhang (agentzh) <age...@gmail.com> wrote:
> Hello!
>
> 2013/8/26 保建国:
>> 谢谢。对于on-cpu/off
>> cpu有所了解，感觉都是利用统计的方法进行分析处理。我想考虑单次操作的延迟分析。也许对oncpu/offcpu理解的还不深刻。我深入研究下。
>
> 你用 ab 或者 weighttp 这样的工具反复执行同一个请求，此时得到的火焰图便是该请求对应的性能分析。
>
> 当然，对于非阻塞 I/O + I/O 多路复用的应用来说，某些外部 IO 资源的延时既不会反映在 on-CPU time 中，也不会反映在
> off-CPU time 中，所以编写专门的各阶段的延时计量工具也是很有用的，同时也是很简单的。
>
>> 同时编写专门的延时分析工具，这个建议也不错。
>>
>
> 在编写专门的延时分析工具之前，建议尽量先使用火焰图工具，因为根据我的线上性能分析经验，后者经常可以给出“全景图”（除了我上面提到的外部 IO
> 延时无法反映的那个限制）。
>
> 比如在我的 off-CPU time 火焰图的幻灯中，也同时使用了许多专门阶段的延时分析工具，比如对单次文件 IO 操作的延时分析和对
> epoll 事件循环的阻塞延时分析。见
>
> http://agentzh.org/misc/slides/off-cpu-flame-graphs.pdf
>
> 一般地，即使是对于单个请求进行分析，也推荐使用压测工具 +
> 量化统计的办法，这样可以很好地降低单次实验所引入的测量误差，除非你单次请求的延时就达到很夸张的水平，比如百毫秒级，乃至于秒级。
>
> 继续抄送给 openresty 中文邮件列表。
>
> Regards,
> -agentzh
>
--
致 礼！
Baul
去甚 去奢 去泰
