Home » 2011 » January

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

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)。可以預期到時候會讓使用量衝上去許多...

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」。

Archives