一百条任务跑完，九十条在两秒内结束，剩下十条用了十几秒。整体平均看起来还行，实际体验被那十条拉低。这种长尾现象在代理IP网速的排查里容易被忽略，因为平均值把问题盖住了。
先分清是整体慢还是少数慢
把每条任务的耗时列出来排序，看分布形状。整体平移偏慢说明是公共环节的问题，多数任务挤在中位附近；少数特别慢说明是个体差异，问题出在那些具体请求上。代理IP网速的这两类问题处理方式完全不同，混在一起查会来回打转。
少数慢的常见来源
常见的有几处：某几条连接恰好落到负载较高的出口上；个别请求触发了对方的频次限制，被延后处理；重传正好发生在数据量较大的那几条上。这些原因都不会在所有请求上出现，代理IP网速的表现因此忽好忽坏，长尾看上去像是随机的。
怎么把这几条挑出来看
记录每一轮最慢的若干条，看它们的共同点：是否集中在某些出口、某些时段、某类目标地址。找出共同点比反复重跑整批任务有效得多，因为重跑会把这些慢的请求重新打散，长尾依旧存在，数据却白费了。代理IP链路上的这类规律，通常几轮就能看出来。
| 分布形状 | 指向 | 处理方式 |
|---|---|---|
| 整体平移偏慢 | 公共环节受限 | 查代理IP的出口带宽与并发档位 |
| 少数特别慢 | 个体差异 | 挑出慢的那几条找共同点 |
| 两者兼有 | 两层问题叠加 | 先处理公共环节再看长尾 |
长尾还有一个来源是重试。失败之后重发一次，第二次成功了，但这一条的总耗时已经翻倍。把重试间隔和次数记进统计，能看出这类被掩盖的慢，否则会被算进正常耗时里，把代理IP网速的基线整体拉高。
平均值看不出长尾，排序才看得出。
平均分好看，不代表体验好。
看分布比看平均更有用。把每轮最慢的几条挑出来对比，代理IP网速的长尾问题通常几次就能定位到具体环节。