Mozilla 推薦的 jsDelivr?

Mozilla 在「jsDelivr – The advanced open source public CDN」這篇文章裡面推薦 jsDelivr 這個服務:

Similar to Google Hosted Libraries, jsDelivr is an open source CDN that allows developers to host their own projects and anyone to link to our hosted files in their websites.

GitHub 當作 origin server,前端目前利用 CloudFlareMaxCDN,配合 Cedexis 的 openmix 服務,綜合這兩家 CDN 提供服務。

既有的 cdnjs.com 是由 CloudFlare 贊助的服務,那 jsDelivr 呢?

看了老半天得到這些訊息:jsDelivr 是由 @jimaek 所發起的服務,而 @jimaek 受雇於 MaxCDN。再加上 Mozilla 上的文章也是 @jimaek 發表,而且只發表過這一篇 (參考 Articles by Dmitriy Akulov),這邊的目的也太明顯...

應該可以每幾天就看一下下面的 comment,不知道什麼時候會引爆利益衝突的問題...

Amazon CloudFront 可以從 Web Console 上看到統計資料了

官方這篇「Announcing Amazon CloudFront Usage Charts for Web Distributions - Track Trends in Requests & Data Transfer」公告說明 Amazon CloudFront 可以透過 Web Console 看到統計數據了:

最近好像補了不少 log 與統計的功能,CloudFront 也趕上這波了 XD

CloudFront 支援 SNI,不需額外每個月 USD$600 的費用...

剛剛看到 Amazon CloudFront 支援 SNI,而且不像 Dedicated IP Custom SSL 需要每個月 USD$600 的費用:「New Features for Amazon CloudFront: Server Name Indication (SNI) and HTTP Redirection」。

目前最大的問題只剩下 Windows XP + IE8 不支援 SNI,台灣還有 19.86% 的人使用 IE8 (不知道 Windows XP + IE8 實際佔多少):


(出自 http://gs.statcounter.com/#browser_version-TW-monthly-201302-201402)

但至少行動裝置上的主力平台都支援了,如果大多數用戶是行動裝置,這個方式可以兼顧 custom SSL domain 與花費...

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 合約到期就整個切過去了?(噗)

冒出很多疑問啊...

GitHub 的網站功能上 CDN 了...

GitHub Pages 上 CDN 了:「Faster, More Awesome GitHub Pages」。

不過 Apex domain (也就是 domain 本身的 hostname) 無法設定 CNAME record,必須透過 A record,就沒辦法用到 CDN 的地區特性了...

CDN 用的是 Fastly,也丟進 SmokePing 監測好了...

Amazon CloudFront 與 Route53 正式公告增加台灣機房...

如同前幾天提到的正式公告了:「New Edge Locations Added in Taipei and Rio de Janeiro for Amazon CloudFront and Amazon Route 53」。

價錢跟預期的一樣,與亞洲區其他點相同。

不過實際上測試,Route53 好像沒看到會導到台灣機房?

CloudFront 有台灣機房了...

這是從 HiNet 機房連到 AWS 官方 d36cz9buwru1tt.cloudfront.net 的 SmokePing 資料:

從中華 HiNet 機房到 test.gslin.org:

  3.|-- 211.22.229.2               0.0%    10    0.2   0.2   0.2   0.6   0.0
  4.|-- 220.128.5.226              0.0%    10    0.4   2.6   0.4  11.9   4.4
  5.|-- 220.128.2.174              0.0%    10    2.7   5.4   2.6  12.5   3.3
  6.|-- 220.128.4.177              0.0%    10    0.4   2.0   0.4  16.2   5.0
  7.|-- 203.75.228.29              0.0%    10    1.3   1.3   1.1   1.6   0.0
  8.|-- 223.26.66.19               0.0%    10    1.7   1.4   1.3   1.7   0.0
  9.|-- 202.133.255.122            0.0%    10    1.1   6.8   1.0  38.8  12.2
 10.|-- 54.230.215.52              0.0%    10    1.2   1.2   1.1   1.3   0.0

從台灣固網 TFN 機房到 test.gslin.org:

  3.|-- 60.199.236.110             0.0%    10    0.3   0.3   0.3   0.5   0.0
  4.|-- 60.199.255.3               0.0%    10    0.3   0.3   0.3   0.3   0.0
  5.|-- 60.199.20.149              0.0%    10    0.2   0.2   0.2   0.2   0.0
  6.|-- 60.199.3.161               0.0%    10   37.9   4.1   0.2  37.9  11.9
  7.|-- 60.199.17.194              0.0%    10    0.7   3.0   0.5  14.1   4.7
  8.|-- 210.62.255.28              0.0%    10   11.0  18.1   1.9 139.9  42.9
  9.|-- 223.26.66.19               0.0%    10    1.5   1.6   1.4   1.8   0.0
 10.|-- 202.133.255.122            0.0%    10    1.9   1.8   1.6   2.4   0.0
 11.|-- 54.230.215.131             0.0%    10    3.8   3.5   1.2   5.4   1.4

雖然官方還沒公佈,但已經上線了,代碼是 tpe50

就路徑與反解資訊看起來是在是方的網路裡,不過不是很確定... 另外 Route53 看起來還沒有導過去,所以是還在 setup?

Anyway,在台灣有 PoP 的 CDN 又多了一家:

所以什麼時候會正式公佈呢...

AWS 進入北京!

早上的時候就有看到消息了,而剛剛在 AWS 老大 Werner VogelsTwitter 上看到他宣佈 AWS 北京區的成立:

官方公告在「Coming Soon - New China (Beijing) Region」這邊。中國大陸的官方網站在「亚马逊 AWS | Cloud Computing in China on Amazon Web Services (Simplified Chinese)」這邊。

一如往常的,有中國政府規範的但書:

This Region will allow China-based and multinational companies to make use of a broad collection of AWS services while remaining in compliance with China's legal and regulatory requirements.

要注意的是,目前列出來的服務並沒有 CloudFrontRoute53,只有看到這樣的說明:

We have been working with a number of local data center, bandwidth, and content delivery partners to bring this Region to life. Companies such as China Net Center and SINNET will provide the infrastructure, network services, and CDN services that are required to support the launch and operation of AWS technology services in China.

繼續觀望看看接下來如何...

Amazon CloudFront 與 Route53 又多了三個 PoP...

AWS 機房多了三個 PoP,分別是菲律賓的馬尼拉、法國的馬賽、波蘭的華沙:「Three More CloudFront / Route 53 Locations - Manila, Marseille, and Warsaw」,所以 Amazon CloudFrontAmazon Route53 也多了這三個機房。

馬尼拉的頻寬費用以及 request 費用與香港相同,實際用 pinger.unimas.my 測發現好像不是連到菲律賓的機房:

Executing exec(ping, -c 5 -s 56, 54.230.158.85)
PING 54.230.158.85 (54.230.158.85) 56(84) bytes of data.
64 bytes from 54.230.158.85: icmp_req=1 ttl=53 time=44.3 ms
64 bytes from 54.230.158.85: icmp_req=2 ttl=53 time=60.5 ms
64 bytes from 54.230.158.85: icmp_req=3 ttl=53 time=60.6 ms
64 bytes from 54.230.158.85: icmp_req=4 ttl=53 time=54.2 ms
64 bytes from 54.230.158.85: icmp_req=5 ttl=53 time=57.2 ms

--- 54.230.158.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 44.345/55.416/60.666/6.026 ms

然後:

;; ANSWER SECTION:
85.158.230.54.in-addr.arpa. 86413 IN    PTR     server-54-230-158-85.sin3.r.cloudfront.net.

看起來好像剛上線而已,還有一些 routing 沒調整好?從 pinger.unimas.my 過去是到新加坡的 server...

用機車方法硬找 code name 結果只找到 maa3 (*.maa3.cloudfront.net) 是印度孟買機房,看起來還是要用其他方式找找看 :o