服务器上跑得很好，用户还是说慢

以前我习惯在服务器上装个测速脚本，跑完看到两百毫秒，就写进周报。

后来对着用户反馈一对，发现完全不是一回事：他那边要三秒，还要先转两圈。那一刻我才意识到，我一直在测一个别人不会遇到的场景。

本机测试的盲区

自己测自己，怎么看都顺眼，问题往往就藏在这份顺眼里。

从服务器往外测，测的是「我这台机器到别人」的单条路径，而且通常还是最优的那条。

用户走的是他自己那条路，中间还有他的运营商、他的地区、他的设备和浏览器缓存。

一台机器测一万次，也代表不了另一个省的手机用户，样本从一开始就不对。

第一看：节点能不能代表用户

这一条决定结论能推多远，覆盖之外的地方，工具不负责。

节点数量不是重点，分布才是，几十个节点扎堆在一个省，等于只测了一个省。

用户八成在华东，全测西部节点，结论对业务没有帮助，只是图表好看。

运营商只覆盖一两家，剩下那家的问题永远测不出来，投诉永远比报告早到。想看清覆盖，用宝塔拨测的网站测速跑一轮，节点列表和分组结果都摆在那儿。

第二看：有没有分段

这一条决定结论能不能用来排查，只有一个数就只能干着急。

只给一个总秒数，你没法判断慢在解析、建连、握手还是下载，最后只能靠猜。

能拆成 DNS、TCP、TLS、TTFB、下载五段，才有排查价值，也才知道该找谁。

还要看它测的是纯 HTML，还是把图片脚本都算了进去，两者的数字不能直接比。

第三看：能不能复测

这一条决定结论稳不稳，也决定你敢不敢写进报告。

单次结果会抖，尤其跨运营商和跨境的那几个节点，抖起来能差好几倍。

能按同一组节点、同一条件连测几次，才谈得上稳定结论，单次只能当快照看。

不能复测的工具，只适合看趋势，不适合下判断，更不适合写进验收报告。

我现在的用法

三步固定下来，谁做都一样，结论也就能互相印证。

在多地区多运营商节点上跑一轮，五段耗时和状态码一起看，平均、最快、最慢节点也都留着。

先按地区分组，再按运营商分组，重点看最慢节点和平均值的差距，差距大说明分布不均。

同一组节点连测三次，只处理每次都出现的那部分，偶发的先记下来观察。

软件负责采数，判断还得自己做。把它当成尺子，别当成裁判，尺子量得准，判断才有依据。

工具选对了，判断才轮得到自己做。