厂商官网上的宣传图,我向来当笑话看，什么“全球节点延迟低于20ms”，什么“智能路由自动优化”，没有我自己的抓包结果，一概不信，这周刚帮一位做户外装备的跨境客户做CDN选型，他们德国站流量不大但图片多，客户点名想用Edgecast，理由是Salesforce后台默认推荐，行，那就测。
测试环境很朴素：一台托管在法兰克福Falkenstein的源站，1Gbps带宽，跑Nginx，页面主体是200张未压缩的商品图（平均每张1.2MB），测试工具用curl的-o /dev/null记录连接和首字节时间，再用真实Chrome无头浏览器跑三遍完整页面加载，所有结果取中位数，对比对象选了Akamai、Cloudflare和Fastly，因为这几家在欧洲都有比较成熟的节点。
第一轮：首字节与冷缓存命中
Edgecast在法兰克福有节点,这个让我意外，因为它的路由表更偏向使用法兰克福作为欧洲核心接入点，实测冷缓存下，Edgecast的TTFB（首字节时间）是178ms，比Cloudflare的141ms慢，但比Akamai的215ms快，Fastly成绩最好，119ms，注意，这是冷缓存，意味着边缘节点需要回源，Edgecast回源路径走的似乎是电信级专线，TTFB波动小，标准差只有23ms，而Cloudflare冷缓存时回源会被限速到约50MBps，明显有内部带宽压制。
Edgecast CDN实测，法兰克福机房视角下的真实性能与回源代价
第二轮：缓存命中率与图片加速
这个客户最看重图片加载速度,Edgecast的缓存策略很有趣，默认对JPEG/PNG会缓存5分钟，但可以手动设置长缓存，我按照客户实际场景设置了24小时缓存，并开启它的“Image Optimization”模块（压缩+WebP转换），这一下数据拉开了。
Edgecast命中后TTFB降到32ms,体积因为WebP转换，平均从1.2MB降到290KB，整体页面加载时间从原来的6.8秒变成2.1秒，Cloudflare同样开了Polish（WebP压缩）后，命中TTFB是28ms，压缩后体积305KB，页面加载时间1.9秒，看上去差不多，但Edgecast有个隐藏问题：它的图片优化功能只对“普通缓存命中”的请求生效，如果是带查询参数的URL，默认不缓存，这导致我测试的少数带签名参数的图片直接回源，TTFB飙到460ms，这点Cloudflare做得更傻但更稳——所有图片只要无Cookie都会缓存，不管参数。
第三轮：动态内容与API回源
电商站总有些动态接口,比如库存查询，Edgecast的动态加速（Dynamic Site Accelerator）是单独计费的，我这次测的是标准CDN，所以动态请求全部回源，实测Edgecast对动态请求的转发延迟偏高，回源用时比Cloudflare多45ms，原因可能是Edgecast节点间路由不是最短延迟，而是按流量成本优化，Akamai在这个场景下表现最好，回源延迟只比直连源站多8ms，Fastly更离谱，直接穿透，多4ms，但Edgecast有一个好处：它在回源连接复用上做得很好，连续100个动态请求，TCP握手只发生了3次，而Cloudflare是37次，这对电商后台的MySQL连接池压力是实质性的改善。
第四轮：稳定性与限速门槛
我同时挂了探针,每5分钟请求一次同一个图片URL，跑了24小时，Edgecast的可用性是100%，但下载速度有明显阶段性波动——欧洲早晚高峰时，单连接下载速度从稳定的12MB/s掉到7MB/s，且不恢复，这不是节点拥塞，更像是Edgecast的单连接限速策略，Cloudflare免费版反而一直稳定在9MB/s，Fastly则能飙到极限带宽，Edgecast对“大文件”的默认单文件大小限制是5GB，这个对3D模型下载的客户不够用，需要在后台手动开大，而Fastly没有限制。
结论放在最后，不吹不黑。
Edgecast作为老牌CDN,强项是缓存命中率、图片压缩效率、回源连接复用，以及冷缓存时的稳定性，适合图片多、动静分离明确、对回源数据库压力敏感的电商站点，尤其是Salesforce Commerce Cloud用户，因为它有原生集成，省去配置麻烦，但如果你依赖查询参数做图片版本控制，或者动态API请求占比很高，又或者希望单连接带宽不被限制，那Edgecast不是最优选，Cloudflare胜在动态请求和价格，Fastly胜在灵活性和速度，Akamai则是综合但贵。
这次测试之后,我给我的客户建议是：不换，现在搭一个边缘计算层，把带参数的图片请求重写为无参数路径，然后继续用Edgecast，但下一次预算审批时，我会让他认真测一下Fastly，毕竟CDN这东西，不是名声越大越好，是你源站的脾气和它合不合。
发表评论