Akamai 與 EdgeCast 混用的效果...

EdgeCast 官網上丟出來的「The Positive Performance Impact of a Dual CDN Strategy」這篇 PR 稿引用了 Optimizely 的「The Most Misleading Measure of Response Time: Average」。

EdgeCast 官網上的 PR 稿當然不會提到 Akamai 的名字,但在 Optimizely 上有說明:

At Optimizely, we had already been using Akamai, one of the world’s fastest and most reliable CDNs, so we decided to try adding another. We tested a balanced CDN architecture, combining Akamai with EdgeCast, another leader in the CDN space.

可以看到 99 percentile response time 大幅改善:


不過看不出來是怎麼測試 CDN Balancing 這個方法啊?依照白皮書的說明:

Prior to introducing CDN Balancing, Optimizely’s experiment code was stored in a JavaScript file that sits on Akamai’s CDN, one of the fastest and most reliable CDNs in the world. The code in this file is important because it’s responsible for making client-side changes to a page and serving them to visitors according to the targeting and A/B testing criteria set up by the Optimizely customer who created the experiment.

看起來是對 js code 測試,應該是 cdn.optimizely.com 這個 hostname,而 optimizely.com 的 DNS 放在 Dyn 上。

猜測應該是對 EdgeCast 有服務的地區丟到 EdgeCast 上 (美國的部份應該可以切割到「州」),其他的則丟到 Akamai 上?不過現在怎麼查都是 EdgeCast 啊,從馬來西亞查也是丟到 EdgeCast 的 CDN 上 (然後被導到新加坡)。

不過,在北美 EdgeCast 會比 Akamai 快這麼多應該是因為 EdgeCast 有兩個平台,一個是 for large files,一個是 for small files,兩個平台最佳化時調整的參數應該不同,針對大檔案的部份會計較 thoughtput,針對小檔案的部份會計較反應時間。Akamai 可能就是輸在這邊...

也有可能是因為 EdgeCast 的反應時間比較好,然後 Akamai 合約到期就整個切過去了?(噗)


3 thoughts on “Akamai 與 EdgeCast 混用的效果...”

  1. 您可以试试我和朋友在搞的 tool.17mon.cn,尤其是 traceroute 功能,我们在 IP 库上下了不少功夫,也请多指教。

Leave a Reply

Your email address will not be published. Required fields are marked *