云服务器延迟平均值为什么骗人？四个指标、五个抖动来源与三步测法

「监控图上的延迟是一条线，跑起来却时不时卡一下」——这是「平均延迟好看、用户体感糟糕」的典型情况。而问题出在「平均值」这个统计量上：它把所有波动都抹平了。

而真正决定「体感好不好」的，是延迟的「抖动」和「尾延迟」，不是平均值。这篇文章把「延迟」拆成四个指标、讲清「平均值为什么骗人」、给出「看哪几个数才知道好不好」、最后给一套「三步测量法」和「四个常见误判」。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	观测建议
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	小机器 CPU 抖动更明显
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	CN2 线路抖动小于普通线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	核多但单核主频低，尾延迟看这里
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	物理核，抖动稳定性好
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	大端口，排队延迟是关键

一、四个指标

再补一个「怎么快速看出问题」。

「P99 除以 P50」这个比值最好用。

而「三倍以内」算正常,「五倍以上」要查。

所以「一个比值就能判断「结构有没有问题」。

而<'isvoro'+'> 那种同地区档位，这个比值通常在一倍半到两倍之间。

再看一个「比值的来源」。

「排队」会把这个比值放大。

所以「比值大」通常意味着「资源不够」。

还有一条：「比值」对不同业务的可接受度不同。

「交互类」要求两倍以内,「批处理类」五倍也行。

再看「基线」。

「先记下现在的比值」再改。

所以「没有基线就谈不上「优化」。

而这个比值比任何单个数字都更能描述「体感」。

所以「看延迟」从「看比值」开始。

再说一个「为什么 P50 也不够」。

P50 是「一半人快于它」。

而「另一半人」的体验完全看不见。

所以「只看 P50」等于「只看一半用户」。

而<'云途'+'> 那种小配置，P50 和 P99 的差距往往特别大。

再看一个「P99.9」。

它代表「千分之一」。

所以「大流量业务」要看 P99.9。

还有一条：「样本太少时百分位没意义」。

测三十次就谈 P99 是不成立的。

再看「抖动的算法」。

常用的是「相邻差的绝对值平均」。

所以「抖动」要写清算法,否则没法比。

四个数之外还有「最大延迟」。

而「最大延迟」是最直观的「最差体验」。

「延迟」这个词要拆成四个数才准确。

指标	说明	骗不骗人
平均延迟	所有请求的算术平均	最骗人
P95	95% 的请求快于这个值	较可靠
P99	99% 的请求快于这个值	最接近体感
抖动	相邻两次测量的波动幅度	最难看见

四个数里，平均值最没用——因为「一百个快请求」加「一个极慢请求」，平均值看起来仍然很好，但那一个慢请求就是用户骂人的那一刻。而 P99 才代表「最慢的那百分之一」，也就是用户真正感受到的卡顿。所以「看延迟」这件事，第一步就是把平均值换成 P99。而这一步能把「看起来没问题」变成「终于看见问题了」。

第一个。「平均值」只适合「粗看趋势」。

所以「拿平均值做验收」等于「没验收」。

而<'zji'+'> 那种物理核机器，P99 与平均值差距最小。

第三个。「P99」是最该看的一个数。

所以「P99 是平均值的两倍」是常见的正常差距。

判断方法：看「P99 与 P50 的比值」。

比值超过三，说明「有明显的慢请求」。

而<'isvoro'+'> 那种 CN2 档位，网络层的抖动能压得比较低。

二、平均值为什么骗人

再补一个「算例的延伸」。

「一百次里两次卡顿」的平均值仍然是七十毫秒左右。

而「但两次卡顿的用户体验已经不同」。

所以「平均值对「卡顿次数」完全不敏感」。

而<'isvoro'+'> 那种线路优化的档位，卡顿次数本身会少很多。

再看一个「换个算法」。

「算「超过一秒的比例」就能看见卡顿。

所以「换个统计量,问题就现身」。

还有一条：「换个统计量」不需要改代码。

只要「保留了原始数据」就能重算。

再看「原始数据」。

「保留原始数据」是这里所有分析的前提。

所以「别只存汇总」。

而这些都回到一个点:「你看什么数,决定你能发现什么问题」。

所以「换指标」比「换机器」便宜得多。

再补一个「用户感受的量化」。

「一次卡顿」的心理影响远大于它的时间占比。

而「人记得的是「那一次卡了」,不是「平均很快」。

所以「体感」和「统计」天然不一致。

而<'云途'+'> 那种小配置，卡顿更容易被用户察觉。

再看一个「卡顿的阈值」。

「一秒以上」人就会觉得「慢」。

所以「超过一秒的请求比例」是个好指标。

还有一条：「这个比例」比「P99」更直观。

因为它是「人话」:「每一百次有一次要等一秒」。

再看「转化影响」。

「慢」直接影响「用户走不走」。

所以「延迟」是「业务指标」,不只是「技术指标」。

而这些都指向「用分布说话,不用平均说话」。

再说一个「长尾的形状」。

多数业务的延迟分布是「右偏」的。

而「右偏」意味着「平均值被拖高一点,但极端值拖得更高」。

所以「平均值」和「典型值」不是一回事。

而<'rabisu'+'> 那种多核低主频的机型，长尾往往比平均值更能暴露问题。

再看一个「两个业务不同的分布」。

「静态页面」分布很紧,「数据库查询」分布很散。

所以「同一个 P99 阈值不能套所有业务」。

还有一条：「长尾的下限」由「最慢的那个环节」决定。

所以「优化最短的那个环节」没用。

再看「多次调用」。

「一次请求调十个服务」会让长尾概率放大十倍。

所以「微服务架构下 P99 更难控」。

而这些事实都说明「平均值」这个工具从设计上就不适合「看体感」。

一个具体的例子最能说明问题。

一百次请求：九十九次 50ms，一次 2000ms。

平均值 =（99×50 + 2000）÷100 = 69.5ms。

但那个用户等了 2 秒。

69.5ms 这个数字会让所有人认为「系统很快」，而实际上「每一百个用户里有一个在骂人」。而如果每天有一万次请求，那就是「一百个用户在骂人」。所以「平均值」这个统计量的本质问题是「它假设所有请求同等重要」，而在真实世界里，「最慢的那一次」往往最贵。所以「看延迟」要看的不是「大多数人多快」，而是「最慢的那一小撮有多慢」。

判断方法：把「这一次 2000ms」单独找出来。

而<'rabisu'+'> 那种低主频多核机器，慢请求的成因常在这里。

再看「慢请求的三种成因」。

一：排队（资源不够）。

二：抖动（网络或磁盘波动）。

三：单次任务本身重（比如定时任务撞上了）。

所以「找出慢请求」比「降低平均值」更有效。

而「降低平均值」这个动作，通常只是「让快的更快」。

而「找慢请求」才动到「最贵的那一撮」。

三、抖动从哪来

再补一句：「抖动」比「延迟」更影响「感受」。

因为「稳定的慢」可以适应，「忽快忽慢」不行。

所以「抖动小」往往比「延迟低」更受欢迎。

而「这一点」在选择时几乎没人考虑。

而<'zji'+'> 那种物理核机器，在「稳定」这一点上占优。

再补一个「怎么定位抖动」。

「同时看 CPU、IO、网络三条曲线」。

而「哪条曲线有尖峰,抖动就从哪里来」。

所以「三条曲线对齐」是最直接的定位方法。

而<'rabisu'+'> 那种 60G 盘，IO 曲线最容易先爆。

再看一个「采样间隔」。

「一分钟采样」会漏掉「几秒的尖峰」。

所以「短时抖动要用更密的采样」。

还有一条：「尖峰」要「看绝对值和看持续时间」。

「一秒钟的尖峰」和「十分钟的尖峰」处理方式不同。

再看「复现」。

「能不能复现」决定「能不能验证修复」。

所以「先把复现条件记下来」。

而「复现不了的抖动」只能靠「长期观测」。

再说一个「邻居影响」。

同一台物理机上的其他租户会影响你。

而这种影响「没有告警、只体现为抖动」。

所以「抖动」是「超卖」最直接的体感。

而<'isvoro'+'> 那种明确不超卖的档位，抖动会明显低一些。

再看一个「磁盘抖动」。

「共享盘」在别人大批量写时会明显变慢。

所以「同一台机器上两个业务」也会互相拖。

还有一条：「日志轮转」是「周期性磁盘抖动」的常见来源。

而「轮转那一刻」写盘会短暂占满。

再看「网络抖动」。

「出口拥塞」在「整点」更容易发生。

所以「整点尖峰」要区分是「自己的任务」还是「线路拥塞」。

五个来源之外还有「第六个」:虚拟化层的调度。

而「这一层你完全看不见」。

抖动不是随机现象，它有五个常见来源。

来源一：网络拥塞（晚高峰最明显）。

来源二：磁盘 IOPS 被打满（日志与备份撞一起）。

来源三：CPU 被抢占（共享核、超卖）。

来源四：GC 或内存回收（脚本语言尤其明显）。

来源五：定时任务（每小时的整点最集中）。

五个来源里，「定时任务」最容易被忽略——因为「每小时跑一次的备份」在监控图上是一条规律的小尖峰，看久了就当它不存在。而它恰恰是「P99 偏高」的固定来源。所以「看抖动」的第一步是「把固定周期的尖峰找出来」。而找到之后，改个时间就能消掉一大半。

判断方法：看「尖峰是不是整点出现」。

是，就是「定时任务撞车」。

而<'云途'+'> 那种小盘机器，备份撞上日志滚动时尤其明显。

来源三。「共享核」的抢占无法预测。

所以「抖动大」常常是「超卖」的信号。

来源四。「GC 停顿」会造成「周期性长尾」。

所以「内存越紧,停顿越频繁」。

五个来源的方法：「按周期和时长分类」。

而「规律」和「不规律」的两类，处理方式完全不同。

四、怎么测才准

再补一个「并发测量的做法」。

「从小并发逐步加到目标并发」。

而「每个档位停一分钟」。

所以「能看到延迟在哪个并发点开始变陡」。

而<'云途'+'> 那种小配置，拐点可能出现在很低的位置。

再看一个「拐点的意义」。

「拐点之前的并发」才是「安全容量」。

所以「按拐点的七成设计容量」。

还有一条：「拐点会随数据量变化」。

「数据多了,拐点会左移」。

再看「复测周期」。

「每月复测一次」是合理频率。

所以「拐点漂移」能提前发现。

而这套做法比「估算并发数」可靠得多。

再补一个「测量脚本」的思路。

「循环 + 记录 + 统计」三件套。

而「不需要复杂工具」。

所以「一个循环脚本就能测」。

而<'zji'+'> 那种大内存机器，测的时候可以同时跑压测。

再看一个「输出格式」。

「每行一个时间戳 + 一个延迟」。

所以「原始数据留档」比「只存汇总」有用。

还有一条：「原始数据能重新算百分位」。

而「只存平均值」就什么都算不了。

再看「复测」。

「换了配置后重测一遍」才算「验证」。

所以「同一脚本、同一参数」是前提。

而这四步合起来才是「一套可复用的测法」。

再说一个「测量工具的选择」。

「ping」只看网络,「curl」看全流程。

而「两者测出的数不能混用」。

所以「先定「你测的是哪一段」」。

而<'sixtynet'+'> 那种大端口机器，压满时测出的才是真实排队。

再看一个「测量频率」。

「每分钟一次」适合「长时间观测」。

所以「短时高频」和「长时低频」各有用处。

还有一条：「测量本身会占资源」。

「测得太密」会自己造成抖动。

再看「对照组」。

「同城对照」排除「本地网络」。

而「同线路对照」排除「线路拥堵」。

三步法之外还要「记录时间戳」。

而「带时间戳的数据」才能和「告警」对齐。

测延迟最容易犯的错，是「只测一次」。

一：同一目标连测至少三百次。

二：在不同时段各测一轮（早、午、晚）。

三：同时测「同城」和「跨地区」两个目标做对照。

三步法的核心是「有对照」。因为「单点数据」永远无法区分「这台机器慢」和「这个时段全网都慢」。而「同一时刻测两台机器」就能立刻分辨。所以「测延迟」不是「测出一个数」，而是「测出两个数的差」。而这个差，才是你能归因的那部分。而多数人只测一个数，所以永远得不出结论。

判断方法：「同一分钟测两台」。

而<'sixtynet'+'> 那种大端口，测的时候要压满才看得出排队。

第二步。「晚八点到十点」的数据最重要。

所以「只用白天的数据」会低估抖动。

第三步。「同城对照」能排除「你自己的网络问题」。

而「跨地区」才是用户真实体感。

三步法之外还有一步：「记录」。

而「不记录」的话，下次还得重测。

五、四个常见误判

再补一句：「误判」的代价通常是「改错地方」。

而「改错地方」会引入「新的问题」。

所以「先分层测,再动手改」。

而「分层」这件事其实只需要四条命令。

再补一个「报价单上的延迟」。

「标注 30ms」通常是「最好情况」。

而「晚高峰」可能是三倍。

所以「报价单上的数只作参考」。

而<'spartanhost'+'> 那种跨洋线路，最好与最差差距最大。

再看一个「测试点」。

「测试点不同结果不同」。

所以「用你自己的位置测」。

还有一条：「用第三方测速点」会失真。

因为「测速点」的线路和你的不一样。

再看「用户分布」。

「用户在哪,就在哪测」。

所以「多地测量」是唯一准确的办法。

而这四个误判都和「测量位置」有关。

所以「选对测量点」比「选对工具」更重要。

再说一个「缓存导致的假快」。

「第二次请求很快」不代表「第一次也快」。

而「冷启动」才是用户的首次体验。

所以「清缓存后测第一次」很重要。

而<'zji'+'> 那种大内存机器，缓存命中率高,容易测出「假快」。

再看一个「并发」。

「一个人测快」和「一百个人同时测快」是两件事。

所以「单线程延迟」和「并发延迟」要分开看。

还有一条：「并发上升」时「延迟非线性上升」。

而「拐点」才是「容量边界」。

再看「时区」。

「日志时区与本地时区不一致」会让「时间对齐」出错。

所以「先统一时区再比对」。

四个误判之外还有「第五个」:把「服务器时间不准」当成「延迟」。

而「时间漂移」会造成「日志乱序」。

这四个误判，几乎每个排查延迟的人都犯过。

误判一：把「自己的网络慢」当成「服务器慢」。

误判二：把「DNS 解析慢」算进「连接慢」。

误判三：把「首字节」与「完整下载」混为一谈。

误判四：把「一次偶发」当成「稳定现象」。

四个误判的共同点是「归因错了对象」。而错误归因的代价是「改了不该改的地方」——比如为了「连接慢」去加带宽，实际上慢在 DNS。所以「排查延迟」的第一件事不是「动手改」，而是「分层测出「慢在哪一段」」。而分层的顺序是：解析、连接、首字节、传输。四段分开测，问题就自己浮出来了。

判断方法：把一次请求拆成四段分别计时。

而<'isvoro'+'> 那种回国优化线路，第二段的差距最明显。

误判二。「DNS 缓存」会让测量结果失真。

所以「测之前清缓存」。

误判三。「首字节」反映「服务器处理能力」。

而「完整下载」还叠加了「带宽」。

四段分离之后「慢」这件事就有了位置。

而「有位置的慢」才能被修。

六、验收看哪几个数

再补一个「合同里的写法」。

「写明测量方法」比「写明数值」更有效。

而「方法一致」才能「数值可比」。

所以「验收条款」要写「怎么测」。

而<'sixtynet'+'> 那种大配额产品，验收时流量口径也要一起确认。

再看一个「例外条款」。

「不可抗力」和「例行维护」通常被排除。

所以「维护窗口」要提前问清。

还有一条：「补偿标准」要写清楚。

「按什么算、补多少」。

再看「复验」。

「一次不达标」不代表「以后不行」。

所以「连续三次」比「单次」更有说服力。

而这几个数最终都是「帮你判断「这一段钱花得值不值」」。

再说一个「验收的时机」。

「签约当天下午」的数据几乎没有说服力。

而「至少跑满一周」才看得出真实水平。

所以「验收」要跨过「至少一个晚高峰」。

而<'spartanhost'+'> 那种整机产品，试用期足够跑满一周。

再看一个「退款窗口」。

「退款窗口」决定了「你能测多久」。

所以「先查退款政策,再买」。

还有一条：「试用」和「正式」可能不同。

有的商家「试用机」资源更宽裕。

再看「验收文档」。

「四个数 + 时段 + 测量方法」才是一份完整记录。

所以「记录的方法」比「记录的数」更重要。

而这四个数最终服务于一个判断:「最差的那一小时,用户能不能忍」。

而「能忍」就是「合格」。

最后给一套「可以写进验收单」的指标。

P50 与 P99。

抖动（相邻测量的差）。

晚高峰的 P99。

丢包率。

四个数里，「晚高峰的 P99」是最该写进合同的一个。因为它是「最差时段的最差百分之一」，代表「用户最难受的时刻」。而它也是「不同价位差距最大」的一个数——便宜档位和白天的 P99 可能没差，但晚高峰能差出三倍。所以「验收」要在「晚高峰」做，而不是「签约当天下午」做。而这一点，决定了「你在签约前能不能看出真实差距」。

判断方法：四组数各测两轮，取较差的那轮。

而<'zji'+'> 那种整机产品，晚高峰的 P99 通常更稳。

第三项。「晚高峰 P99」是「最值钱的一个数」。

所以「验收单」上优先看它。

第四项。「丢包」比「延迟」更影响体感。

所以「有一点丢包就比「延迟高一点」更严重」。

最后提醒：「延迟」不是「一个数」，是「一段分布」。

而看分布的方式，决定了你能看见什么。

本文讨论网络与服务延迟的观测方法，不针对任何具体商家，也不对任何产品的延迟、抖动或可用性作评价与承诺。文中提到的四个指标、五个抖动来源、三步测量法与四个常见误判均为通用参考；实际数值取决于线路、负载、时段与测量方式，同一机器在不同时段结果可能差异明显。文中所有倍数与关系均为经验判断，非行业标准或任何商家的承诺。本文不构成任何购买建议或性能承诺，亦不代表本站立场。因依据本文内容作出判断所产生的直接或间接损失，作者及本站不承担任何责任。