Netflix 公佈北美 ISP 對 Netflix 的速度...

Netflix 官方的網誌上公佈:「Netflix Performance on Top ISP Networks」。

目前 Netflix 有 AkamaiLevel3 兩家 CDN 提供服務 (不確定還有沒有其他的),在最後一段還說要每個月更新這些資料,是打算反過來對 ISP 施壓嗎?:

We'll update these charts monthly, and we welcome questions, comments and suggestions to help improve our understanding of Netflix performance on top ISP networks.

AWS API 的認證方式

Amazon Web Services 有提供很多服務,有的早在「雲端風潮」前就有,有的是最近才推出的。把 AWS Documentation library 每個服務的 API 認證方式看完一遍後,只能苦笑對使用 AWS API 的人致敬...

有幾個心得與感想:

  • 文件雖然套用同一組模板 (用 frame 切開,左邊索引,右邊內容),但其中的寫法並沒有統一。理論上每個 API 都會有的 API 簽名環節在不同的文件裡可能會在不同的章節出現。
  • 認證的方式不一致:
    • 早期的服務很亂,大多都是以 SOAP 為基礎的 API,尤其是跟錢有關的這塊特別明顯 (因為 Amazon 很早就 API 化)。
    • 一開始出來的 S3 使用的是 REST 概念,簽名的值放在 HTTP Header 內,欄位名稱是 AuthorizationCloudFront 是 S3 的延伸,所以認證方式與 S3 相同。
    • 但與 S3 同時期推出的 EC2,以及後來大多數的服務,都是以 GET 為基礎。這時候兩套系統的 API 設計邏輯就不同了。
    • 最近出的 Route53,又再引入了 REST 概念,但欄位名稱為 X-Amzn-Authorization,要放的簽名格式又改變了...

這也是為什麼沒有一套 library 可以一直吃遍 AWS 服務的關係,API 的設計讓人感覺頗疲倦... XD

將 search.cpan.org 的 source 部份加上 SyntaxHighlighter

在「CPAN 的 Greasemonkey 工具…」這邊提到打算寫一個 Greasemonkey script,將 CPAN 上面的 source code 部份加上 syntax highlight,因為有不少現成的 Highlighter 是 javascript-based,所以程式只要套一套就可以了...

Greasemonkey 的程式在這:「CPAN Syntax Highlight」。

使用前:

使用後:

CPAN 的 Greasemonkey 工具...

Userscripts.org 翻一些工具,發現有些 script 看起來還蠻有趣的。像是「CPAN Search Dependents」會在搜尋頁列出模組的 dependency 數量。

不過,用過以後發現他的優點是可以先在搜尋頁看出來有哪些 module,至於 script 本來做的事情 (計算 dependency 的數量) 反而不是重點...

等下來寫個可以把 Syntax Highlight 加進去的工具,看了一下 CPAN 的頁面,操作這些 DOM element 應該不難...

mod_fcgid 與 PHP

先不論效能之類的問題,mod_fcgidPHP 的設定比 mod_fastcgi 簡單許多。(參考之前寫的「apache22 (worker) + mod_fastcgi + php5-fcgi」這篇文章)

首先是把 module load 進來:

LoadModule fcgid_module libexec/apache22/mod_fcgid.so

再來是把副檔名加上去,以及告知什麼副檔名要用什麼程式包:

AddHandler fcgid-script .php
FcgidWrapper /usr/local/bin/php-cgi .php

就這樣而已... 預設會跑一隻 php-cgi,需要的時候會再多拉幾隻。以他的方式看起來 code segment 不會共用,這種設定方式給小站台用還可以...

接下來看看有沒有辦法在 .htaccess 內直接吃本地的 FastCGI process...

六月的 IPv6 測試...

今年 6/8 將會有超大的 IPv6 測試:「World IPv6 Day has Facebook, Google & Yahoo Support」。

包括 FacebookGoogleYahoo 都會上線測試,另外最大的兩個 CDN 業者 AkamaiLimelight Networks 也都會上線測試。

雖然沒有說明細節,但猜測這次的 IPv6 測試應該是將 Facebokk 的 www.facebook.com、Google 的 www.google.com,以及 Yahoo 的 www.yahoo.com 直接增加 AAAA record (也一樣保留 A record),然後看看結果如何。而 Akamai 與 Limelight Networks 應該是配合有意願的客戶上線測試。

以目前看起來,6/8 的測試會是一個「開始」,這次的測試不會有結束的時候,藉機順便轉換到 IPv6 上。剛好借測試的名義打破雞蛋問題。Google 的測試不知道會不會將 YouTube 部份影片丟上來測,這對 IPv6 的轉移會影響很大:如果 IPv6 bandwidth 夠大,就會有更多 ISP 會建立 IPv6 的環境。

大多數人沒有 native IPv6 環境,多是透過 tunnel 之類的環境使用 IPv6 (尤其是 192.88.99.1 這組 Anycast-based 的 6to4 tunnel)。可以預期到時候會讓使用量衝上去許多...

AWS 的 Elastic Beanstalk...

這相當於 Amazon 跳下來自己做 Java 版的 Heroku:「AWS Elastic Beanstalk: A Quick and Simple Way into the Cloud」(CTO Werner Vogels 的文章)、「Introducing AWS Elastic Beanstalk」。將整套 Amazon Web Services 的技術整合起來,變成 PaaS:「AWS Elastic Beanstalk」。

由於是 Java,所以用 Java 實做的 PHP5 又被拿出來玩了:「PHP on AWS Elastic Beanstalk」:

在 Google Search 上面可以看到一些站台了:

jQuery 對效能的調整...

TwitterjQuery 1.4.2 換到 1.4.4 以後,發現在捲頁時的效能變得很差:「About that slowness on Twitter…」。

這件事情讓 John Resig 在他的 blog 上發表了一篇文章,發現原因在「$something.find(".class")」這種用法,成為壓死駱駝的最後一根稻草:「Learning from Twitter」。主要的原因是 querySelectorAll(".class") 比起 getElementsByClassName() 慢了一些,而 Twitter 的寫法會使得這個 function 的效能明顯放大到影響整體效能的程度...

文章以及 comment 有給一些建議 (cache selector 與針對 scroll event 的處理),記起來以後應該會有幫助...

Google Apps 的 Uptime 計算方式調整 (對使用者有利的方向)

Google 改變了 Google Apps 對 Uptime 的計算方式:「Google Apps Removes Scheduled Downtime Clause From SLA; Gmail Had 99% Uptime in 2010」(TC)、「Destination: Dial Tone -- Getting Google Apps to 99.99%」(Google 官方新聞稿)。

之前的條款內允許 Google 將「排定的維護停機」排除在 downtime 計算外,現在 Google 決定拿掉這條例外條款。然後在文章下面故意提到 Microsoft 的服務:

Comparable data for Microsoft BPOS® is unavailable, though their service notifications show 113 incidents in 2010: 74 unplanned outages, and 33 days with planned downtime.

有興趣看新版 SLA 的人可以連結到英文版的頁面上:「Google Apps Service Level Agreement」。