CloudFlare 的速度...

CloudFlare 是一種 CDN 服務,相較於其他 CDN 會被歸類到 AkamaiDynamic Site AcceleratorLimelight NetworksDynamic Site Platform,或是 EdgeCastApplication Delivery Network

這類型的 CDN 加速服務,如果用在完全沒有考慮最佳化的網站上,效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上,反而會因為軟體已經做了不少處理,上了 CloudFlare 反而因為多了一層而變慢。

不過會變慢多少呢?有人跳下去測試寫報告了:「Cloudflare Showdown」,如果懶得看中間的數據,可以看最後的結論「Conclusion」。

如果用在已經最佳化過的網站上,用 CloudFlare 會慢不少,如果是 WordPress 及其他 open source 軟體,最好的情況是快一點點,但最差的情況會慢個幾倍... 作者下的結論是「不要用」。

跟預期差不多,動態資料的加速基本上是個商業包裝而已,真正需要加速還是得自己把可以 cache 的部份切割出來。

sitespeed.io 網站測速

sitespeed.io 是一個 open source 軟體,讓開發者可以測試網站的效能,然後輸出 html 報表:「Do you sitespeed?」。

執行需要 Java 1.7+ 以及 PhantomJS,我是在 FreeBSD 上跑 (Java 的部份是用 java/openjdk7),另外根據文章裡第三個 comment,在 Windows 上用 Cygwin 也可以跑。

./sitespeed.io -u http://ptt.cc/ -d 1 -o img 跑出來後會有一整個目錄的報告,包括了 summary 以及所有頁面的清單 (後面這兩個連結是跑完後用 s3cmd sync 丟上 S3 的):「ptt.cc - Summary of the sitespeed.io result」、「ptt.cc - All pages information」。

每一頁都有細項說明,像是首頁 /index.html:「Page data, collected by sitespeed.io for page - http://www.ptt.cc/index.html」。

不過我更感興趣的是 PhantomJS,不知道可以做多少事情...

AWS EBS 的改善...

AWS EBSAmazon Web Services 平台上的永久性儲存空間 (一般開起來的空間在 crash 後會消失),不過 EBS 的效能 (速度與 IOPS) 一直讓大家很頭痛,要硬撐 IOPS 的方式是透過四個 EBS volume,上面用 mdadm 跑 RAID0...

這幾個禮拜 AWS 丟出了兩個方案出來,提供不同的選擇...

首先是帶大容量 SSD 空間的 instance,參考「AWS 推出高速 I/O 的 EC2 instance」,這對於 cache 類的應用相當適合...

而昨天則是介紹了 Provisioned IOPS 與 EBS-Optimized instances:「Fast Forward - Provisioned IOPS for EBS Volumes」。

Provisioned IOPS 是保障 IOPS 的機制,每個 volume 最高可以到 1000 IOPS。除了每 GB 的價錢比較高以外,另外每個保障的 IOPS 要再收 USD$0.1/month。(本來 EBS 的 I/O 費用還是要計算)

標準的 EBS 約提供 100 IOPS,這個 Provisioned IOPS 架構讓使用者要在上面衝 IOPS 變得更容易...

EBS-Optimized instances 是把 EBS 使用的頻寬獨立出來,目前只支援 m1.large、m1.xlarge 以及 m2.4xlarge 這三種,其中 m1.large 跑到 500Mbps (理論值 62.5MB/sec),後面兩種可以上 1Gbps (125MB/sec),使得服務與 I/O 的頻寬不會互相干擾到...

Firefox 11 將會支援 SPDY Protocol

Firefox 預定在 11 (現在是 8) 支援 SPDY Protocol:「(SPDY) Implement SPDY protocol」,除了 Google Chrome 自家瀏覽器支援外,總算有個大的也要支援了...

所以現在除了 Chrome、Kindle Fire 以外,又多了 Firefox 支援...

不過 ApacheF5 什麼時候會支援呢... mod-spdy 看起來... 呃...

Google 推出的 Page Speed Service

Google 在全球的機房數量當然是一個賣點,不過除了 Geo-based 外,Google 還做了很多很多調整,至於這些調整會不會讓效能變好,就不曉得了...

Google 的說明頁面上以 www.ramkikrishnan.com 這個網站當作範例,目前這個網站是指回 original site,如果你要看輸出效果的話可以設 proxy 到 ghs.google.com 硬抓 www.ramkikrishnan.com 的 html 下來看,我把 diff 結果貼到這邊

可以看出 Google 做了一些事情:

  • 重新判讀 html 後再丟出來,所以有些 html attribute 的順序被改變。
  • 如果配合 IE 的 conditional comments 讀入其他的 css,順序有可能被改變,但不確定是 Google 沒有針對 IE 的 conditional comments 判斷,還是將 css 讀出來後認為順序沒有差異 (我是用 curl 去抓,會因為 User-agent 給不同內容嗎?不確定...)。
  • 上面除了可能是 conditional comments 的處理外,也有可能是把 link 放到 script 後面,或是因為要放到 head 尾段造成的。
  • 會把 © 轉成 ©,但也會把 ' 轉成 ',看不太出來原因是什麼...

目前還看不出來比較複雜的 case,等帳號下來後再實際測試看看會比較準...

Google 公司內網路速度的炫耀文...

Matt CuttsTwitter 上面提到 Google 公司內的網路速度:

首先是 Speedtest.net 的測試速度:(Holy... 那個上載速度超過 100Mbps 啊)

然後是遊戲 (RIFT) 下載的速度:(剩下 7.xGB 的檔案只要三分鐘多就可以傳完)

這真是太炫耀了 =_=

加速 Perlbrew 安裝 Perl 的速度

Perlbrew 0.18 其中一項很重要的功能,是在 install perl 時可以使用 -j 的參數,像是這樣:

perlbrew --force install -j 4 perl-5.12.3

-j 這個參數會傳給 make,同時跑的 job 數量。(make 會處理 dependency 問題,理論上不會有問題)

Linode 512 上面 (Debian 64bits) 只用了 7 分鐘就把 Perl 5.12.3 裝完了 (之前是 21 分鐘),時間就是金錢啊... 細節可以參考 0.18 的 Changes 的說明。