时延的误区

时延 latency(亦称为延时、潜伏时间等),是衡量一个系统性能的重要指标。这里就简单的谈谈在时延这个概念上经常容易犯的几个误区吧。

对于网络服务请求时延等于QPS(请求数每秒)的倒数?
这种理解方式忽略了并发的因素,换句话说,如果假定系统只允许一个并发请求,那请求时延确实和QPS是呈倒数关系。但大多数情况,网络的并发请求是非常复杂的,这直接导致了时延和QPS之间无法直接关联。

时延越小性能越好吗?
同上一个话题的回答,相同并发数的条件下,时延越小越好。

时延等于请求返回时间?
这个是处于对“时延”概念的理解,以一个标准的HTTP请求来说,“时延”这个概念包含了“页面响应时延”、“连接时延”、“页面生成时延”、“网络传输时延”、“数据接收时延”等粗粒度的时延,细粒度的时延更是无法统计。而一个“页面响应时延”是后面的数个“时延”的总和。所以在没有一个合适的定语之前,单单一个“时延”的概念是不具备横向比较的意义的。

ms(毫秒)级的时延是可接受的。
兴许这个问题跟上面一个问题相同,回答是:“要看定语是什么”。
比如说,当我们探讨CPU命令返回的时延时,单位是ns(纳秒10E-9),而到了页面响应时延来看,单位到了秒这个级别。如果说9个数量级的差距可能已经超出了数字的直观理解,那么有个挺有意思的例子可帮你理解这两个单位的区别:如果把1ns放大到1秒的时候,那么同样的比例尺1ms等于40天,1秒相当于150年!

仅用响应延时来衡量性能。
在我们常见的服务中,可以划分为响应延时敏感型任务和吞吐敏感型任务。这两者事实上是互为矛盾的。假象一个任务我们希望它能够尽快的完成也就是上面提到的吞吐敏感型,那势必应该尽量不要它被其他的请求所打扰。同样对于时延敏感型任务,如果希望它能尽快地响应用户发起的新请求,那么它的任务就会被不断的被新的请求处理中断。这种两种模式的矛盾体体现的最明确的实现方式是数据库。

推荐阅读:
事出前些日子有人咨询我:“在某
有感于CPU的各种电源状态描述
如果大家了解一点CPU的知识,
既然都是9102年了,云计算早

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据