幹壞事是進步最大的原動力
Amazon Web Services 上星期公佈了 S3 不同等級的服務：「Announcing Amazon S3 Reduced Redundancy Storage」。
先前 S3 的系統是設計成一年內有 99.999999999% (1-10-11) Durability，這是靠比較高的 replication 數量，以及將資料放在不同機房。而 RRS (Reduced Redundancy Storage) 則是放在單一機房內，replication 數量也比標準的 S3 少，所以成本會比較低，但資料的可靠度也會比較低，只有 99.99% (1-10-4)。
這個新的設計對於比較不重要的資料 (尤其是可以從原始資料再運算得到的，像是縮圖) 可以考慮丟到 RRS。在前 50TB 的部份是標準儲存 2/3 的價錢。
另外 RDS 的部份則是支援跨區 replication 了，可以藉由這種方式提昇一部分的服務可靠度：「Announcing Multi-AZ Deployments for Amazon RDS」。
四月底的時候 Amazon 宣佈 Amazon Web Services 在亞洲區選擇新加坡為其第一個進入的點：「Announcing the AWS Asia Pacific (Singapore) Region」。
以 latency 看，速度比美西的點好很多，主要還是貴在頻寬的費用上，不過有些 ISP 還是會繞去美國再回來，速度就變差了...
終於從沒網路的地方出來了... 兩個禮拜多沒更新 Firefox (3.7，Minefield 版)，這次一更新就發現 GDI++ 失效了，看了一下，似乎是因為 Adblock Plus 把問題修掉並且推出新版的關係？
考慮到美觀與速度之間的妥協，還是把 DirectWrite 關掉...
Amazon Web Services 大約十天前對 ELB 加上了新功能：「New Elastic Load Balancing Feature: Sticky Sessions」，這個功能想要做到同一個 session 所發出的 request 都導到同一台 server 上。以「Elastic Load Balancing with Sticky Sessions」這篇的說明來看，看起來是 Cookie-based。這在商業 load balancer 上是很常看到的功能，後端的 web server 幾乎不用修改就可以維持同一個 session 都導到同一台 server 上。
另外常見的作法是把 session 資料放到 NFS 或是 memcached 上，這樣跨機器也沒問題。
Amazon Web Services 今天推出 Amazon Simple Notification Service (Amazon SNS)，看起來比較像是 Simple Queue Service (Amazon SQS) 的變形：「Announcing Amazon Simple Notification Service」。
Amazon SQS 的架構是 poll-based，而 Amazon SNS 是 event-based，而且允許多個訂閱，可以用 HTTP/HTTPS，以及 Email/Email-JSON (這兩個東西...)，另外也可以丟到 SQS。
價錢的部份，除了需要流量費用以外 (要注意的是只要 in/out SNS 就要收錢，而非跨出 Region 才收)，另外也有 notification 的費用。如果自己改裝成 Sync Job Server (雖然走 HTTP 時 overhead 有點重)，就目前費用看起來還蠻超值的，以 Notification 來算 (所以每次 publish 可能會有很多筆 notification)，每十萬次才 USD$0.06，比起自己租用 EC2 最小台的機器做算是很方便的服務...
Email 的部份 (每十萬封要 USD$0.2) 還沒細看，不確定能實際拿來作什麼，不知道能不能當作 mailing list？
再來想看看還有什麼有趣的用途...
從 2010 的四月開始 (三月底就先公佈了)，在同一個 billing account 下不同服務的頻寬將合併 (並不是所有的服務，請參考官方公告所列的)，然後依照各區 (region) 計算：「Announcing Combined AWS Data Transfer Pricing」，除此以外每個月 Outbound 的第一個 GB 是免費的。
這對於使用量夠大的人才有差異：假設 S3 與 EC2 的 US-East 區 Outbound 都是 10TB，舊的算法會算成兩次 10TB (前 10TB 是 USD$0.15/GB，也就是 USD$3000)，而新的算法則是算成一次 20TB (第一個 GB 免費，前 10TB 是 USD$0.15/GB，再來的 40TB 部份是 USD$0.11/GB，也就是 USD$2599.85)。
10TB/month 大約是平均 33Mbps，用 Amazon EC2 跑 Facebook 外掛遊戲的應該都做的到？不過應該不會 EC2 + S3 混用，而是 EC2 + CloudFront 混用？這樣好像就虛掉了...
玩了幾天 Pacman，整理一些資料...
安裝完成後，預設可以使用的 package repository 可以在 /etc/pacman.conf 內看到，包括 core (目前約 340 個)、extra (~4500)，以及 community (~3400)。
另外有幾兩個測試性質的，預設是關閉的。一個是 testing，另外一個是 community-testing，裡面的量都不多。
除了這些以外，使用者自己也可以提供新的套件，官方有提供 AUR (也就是 unsupported)，任何人都可以註冊並且上傳，也因此所以有可能會包括有安全問題的 code。所以有 TU (Trusted Users) 的制度，當一個 package 使用的人夠多 (在「AUR Trusted User Guidelines」有說明)，而且 TU 確認沒問題後就會 update 到 community 內。
要安裝 unsupported 的軟體必須必須自己下載 AUR 的 source tarball (裡面有 PKGBUILD 以及其他設定)，並且確認沒有 malicious code 後再用 makepkg 安裝。
另外 Gmane 有收 ArchLinux 的 mailing list，習慣用 BBS 讀的人可以抓下來看。
剛剛跑 WebPagetest 才發現 WordPress 把內建的 gzip 的功能拿掉了 (差不多拿掉兩年了)，所以第一個 request 不會被壓縮：「Web page performance test results for http://blog.gslin.org/ Test completed - 03/19/10 22:24:51 from Dulles, VA - 1.5Mbps ADSL」。
可以在 WordPress Codex 上看到說明以及建議的解法：「Output Compression」，不過在 SharkSpace 的主機上用 .htaccess 的方式完全沒效果，還不曉得是什麼問題...
由於首頁的 request 不壓縮與壓縮會有 40KB 以上的差距 (從 63KB 到 18KB)，能夠解決 PHP 輸出的部份其實就解的差不多了，在找了 WordPress 的 Plugin 後，目前是裝 GZIP Output，目前看起來沒什麼問題...
Steve Souders 開了一個「Performance of 3rd Party Content」，分析 3rd party script 的效能。目前已經分析了四個 js。
看完四個 js 的分析後，可以看出來一些 pattern：
document.write (會有奇怪的結果)，就算不是 async script 也應該儘量避免使用。常見的方法是建立一個帶有 id 的 div，然後在 script 內用 document.getElementById() 或是等價的方式取得後在裡面插入元素，或是直接修改 innerHTML。div 再修改的模式時，如果可以先確定 div 的大小，最好在 class 與對應的 CSS 上先定義 (像是廣告的版位)，可以避免頁面 re-layout。Cache-Control 內設定夠長的 max-age (尤其是幾乎不會改動的圖片)。這個計畫應該還會再繼續分析，有興趣的人可以訂 RSS 看。
這次主要是把之前用 jQuery 1.2.6 的需求改寫，改用 getElementsByClassName()、getElementsByTagName() 以及 getElementById() 取得元素，然後用 .innerHTML 直接換掉內容。
由於這次改寫避免使用 unsafeWindow 以及複雜的 GM_* 函式，在 Google Chrome 除了遇到一個小問題之外 (可以寫一段 code workaround)，目前跑起來還蠻正常的。
參考：「Wretch Album Expander」以及 GitHub 上的「gslin's albumexpander」。