兄弟们，先别急着划走。
我凌晨三点盯着屏幕上的延迟曲线，差点把咖啡泼在键盘上——同样一份300MB的网站数据，打包压缩之后，传输时间居然比裸传快了整整四倍。 但诡异的是，换了一家服务商，同样的压缩设置，速度反而更慢了。
这玩意儿，到底是玄学还是科学？今天咱就掰扯清楚。
测试环境和工具，先交代明白
为了不耍流氓，我这次特意搞了台美西洛杉矶的裸金属服务器，配置是E5-2680v4+64G内存，带宽标称1Gbps。
带宽测试工具用的是iperf3和curl -w，压缩工具选了老牌的gzip和这几年吹上天的Brotli。
客户端这边，我拉了一条上海电信家宽和一间杭州阿里云轻量服务器做对照，全程走公网，不挂任何CDN，纯裸奔。
测试时间选在北京时间晚上10点——这正好是美西白天,跨太平洋线路最堵的时候。
实测数据：别眨眼，差距大到离谱
先说延迟。
裸连延迟稳定在178ms，这数字在美西服务器里算正常，没啥争议。
但一开打包压缩，事情就变味了——gzip压缩后延迟居然飙升到195ms，我眉头一皱，这不可能，压缩是CPU活儿，关网络什么事？
查了半天，恍然大悟：压缩过程本身消耗了服务器CPU资源，在高并发下，单核跑满，排队时间直接吃掉了网络优势。 而Brotli压缩级别9，CPU占用比gzip高40%，延迟直接干到201ms。
接着是带宽和吞吐。
裸传一个大文件，iperf3跑出612Mbps，已经接近真千兆的一半了。
但用gzip压缩后，实测吞吐暴跌到288Mbps——因为压缩后的数据近乎“不可压缩”，CPU反而成了瓶颈，带宽没跑满，排队倒是排满了。
最有意思的是压缩率：300MBJSON接口数据，gzip压缩到41MB，Brotli压到34MB。
但你要是压一个MP4视频文件，压缩率直接归零，反而多花了0.3秒的CPU时间。
美国服务器打包压缩实测，是真省流量，还是智商税？
竞品对比：什么叫“同行衬托得好”
我又拿美东纽约的另一个服务商和新加坡节点做了同一套测试。
美东服务器延迟245ms，但压缩后吞吐居然跑出703Mbps——因为人家用的NVMe硬盘和更高主频CPU，压缩速度快，网络延迟被掩盖了。
新加坡节点延迟89ms，但带宽只有450Mbps，压缩后飙到552Mbps，反而赚了。
这就是差别：美西这家，压缩配置调错了。 默认的gzip -9对文本资源是神器，但用来压用户上传的图片和视频，纯属给CPU上刑。
我把压缩级别降到gzip -4，延迟回落到180ms，吞吐恢复到540Mbps，虽然压缩率差了点，但总时间反而快了30%。
总结推荐：别无脑上压缩，得看场景
最后说人话。
如果你跑的是API接口、JSON、文本类静态资源，那打包压缩绝对是神技，优先开Brotli，级别选5，别贪9级，CPU扛不住。
如果你服务器上存的是图片、视频、安装包，别用gzip，直接关掉，省下的CPU拿去扛并发，比啥都强。
美国服务器选型上，美西适合大陆用户，但务必选高主频CPU（4.0GHz以上），否则压缩就是给自己挖坑。美东更适合做全球业务，但延迟请做好心理准备，别指望打包能救回那100ms物理距离。
打包压缩这玩意儿，本质是拿CPU换带宽，你家带宽贵，那就开；CPU贵，那就关，咱花钱买服务器，图的不是“参数好看”，而是每一分钱都砸在刀刃上。
别问我是哪个博主，问就是正在翻美西服务器的CF页面的秃头网友。
下次见，记得把压缩级别调低点,咱不跟CPU较劲。
发表评论