Amazon EC2

這兩天跟 XDiteAmazon EC2,除了拿來跑 apacheMySQLmemcached 外,也有人拿來作為其他的用途。

其中一個比較有名的例子是去年十一月的時候,紐約時報的 Derek Gottfrid 寫了一篇文章,說明了把 1851 年至 1922 年的 TimeSelect 與 The New York Times 轉成 PDF 的過程。

他們已經有 TIFF 格式的圖檔,現在想要轉成 PDF 檔,但原始 TIFF 檔有 4TB,如果在短時間內要轉成 PDF,需要投資不少設備。

由於他之前使用過 Amazon S3,覺得 S3 是一個還不錯的服務,所以他決定嘗試 Amazon EC2。首先先把 4TB 的圖檔傳到 S3 上。再用 Amazon EC2 跑 Hadoop,在上面開 100 台 EC2 instance 轉檔,只花了一整天就把 4TB 的 TIFF 轉完並產生 1.5TB 的 PDF。(Self-service, Prorated Super Computing Fun!)

如果計算 S3 與 EC2 所花掉的費用 (包括 storage、bandwidth、running time),可以在 USD$3000 內解決,總共只花了兩到三天的時間。這是一個還蠻有趣的例子,拿 Amazon EC2 來跑這種需要大量 CPU resource 的工作。

TWNIC 反解問題

這個週末大概要大亂了...

剛剛發現系統異常,一路追查下去發現國內 ISP 一卡車的反解不見了,從上層一步一步 trace 後,似乎是 TWNIC 改設定造成的問題 XD

HiNet 為例,122.116/16 整段都是 HiNet 的 (IP代理發放單位網段:122.116.0.0-122.117.255.255),但 DNS 並不是直接交給 HiNet 管,而是透過 TWNIC 管:

116.122.in-addr.arpa. 86400 IN NS rns2.twnic.net.
116.122.in-addr.arpa. 86400 IN NS rns3.twnic.net.
116.122.in-addr.arpa. 86400 IN NS rns1.twnic.net.

目前 twnic.net 有兩台 NS RR:

twnic.net. 172800 IN NS moevax.edu.tw.
twnic.net. 172800 IN NS ns.twnic.net.
ns.twnic.net. 172800 IN A 192.83.166.11

其中 moevax.edu.tw 已經不會回答了,而 ns.twnic.net 則是傳回不存在 rns{1,2,3}.twnic.net 這些 hostname XDDD

Update:結果是 moevax.edu.tw 恢復了,rns1.twnic.net 還是回 SERVFAIL。所以,這個現象其實很久了?

加快 JavaScript 的速度

最近在研究頁面速度時想到的方法,這個方法對於之後的 JS engine 應該會有幫助,另外也可以解決一個常見的鳥問題。

國外應該有人有提過這個方法,不過我用 Google 翻了一下翻不到,等之後找到再收到 delicious.com

程式碼的精神很簡單:

var a = function() { /* slow code */ };
setTimeout(a, 1);

這樣的好處是:

  • 程式可以馬上跑下去,就算 code 裡面有一些比較慢的動作 (像是透過網路抓圖片回來)。如果 JS engine 有能力使用 OS threading 就能夠避免 block I/O 造成頁面卡住。
  • 在 document 上掛 onready function 有可能會執行不到,原因是頁面中間遇到 JS error 時就不會跑 document 的 onready。但用 setTimeout 的方法就沒這個問題。(只以 IE6/IE7/Firefox3 測試過,不確定其他的瀏覽器是否支援)

抱怨一下,IE 的 JS 速度實在是不怎麼樣...

Chromium 的 nightly builld

剛剛在 Slashdot 的 comment 堆裡看到 Chromium (Open Source 版本 Chrome) 的 buildbot binary (看起來每一個 revision 都有 build):http://build.chromium.org/buildbot/snapshots/

在公司一直抓不下來,只好特地抓 buildbot binary 了...

PS:值得特別說明的,buildbot binary 不需要簽 EULA,所以不會有 Reading Google Chrome's Fine Print 這篇提到的問題。

Google Chrome 的市場佔有率

GetClicky Analytics Service Tracking 2% Google Chrome Usage 這篇文章看到 GetClicky 在 45000 個網站即時統計 (實際上是 15 mins) 出來的結果。

目前我看到的是 1.91400% (reload 後變成 1.87233%... XD),應該會繼續往下跌,不過不知道會跌到什麼地方。

Update:現在是 2.78387% 了... @_@

Google 自己的瀏覽器:Chrome

Google 官方對於 Google Chrome 的公告都出來了:A fresh take on the browser,甚至有漫畫版本的說明可以看...

依照 Google 的說明,這是一套 open source software,rendering engine 是 Apple's WebKit,配上自己寫的 V8 JavaScript engine,看起來又有一堆 web developer 要頭痛了...

最近就會有 beta version 可以下載來看,到時候再抓來測試。

Update:網站「意外洩漏」的截圖被人抓下來了 (都搞這套...),有不少人抓了 Screenshot 可以看,以這些截圖看得出來 Chrome 的設計:Google Chrome Screenshots。剛剛看了才想到,不知道 Chrome 有沒有從 Microsoft 那套學起來,內建一堆自己的東西?順便把 Gears 包進去?

Update:釋出了,在 Google 的首頁就有下載點!另外附上 Acid2 的截圖,看起來沒問題:

可以注意到網址列的處理上,刻意把站台部份與路徑部份的顏色分開:

如果是 SSL 站台的話則是黃底,再把 https 用綠色標出:

如果是過期的憑證會這樣顯示:

Proxy 設定則是直接吃 IE 的設定,預設會打開 DNS prefetch cache,的確有比較順暢... 另外可以用 about:plugins 看到有哪些 plugin 預設就已經被裝起來了,預設有把 Google Gears 裝起來:

另外一個 about:memory 則是可以直接看記憶體用量,包括其他瀏覽器! (居然直接去讀其他 browser 的資訊...)

使用 PHP Framework 的效能問題

PHP Framework 裡會大量使用 require_once(),由於需要判斷是否載入過檔案,require_once() 會使用 realpath() 取得檔案實際路徑資訊當作判斷條件,而這點會有效能上的問題。

其他人其實也遇過,參考:PHP Performance tip: require versus require_once,其中 comment 的部份也說明了目前 Google 到的方法是沒有用的。

FreeBSD libc 裡的 realpath(3) 會使用 lstat(2),而 FreeBSD 的 lstat(2) 因為用到 VFS_LOCK_GIANT(9),所以在 FreeBSD 上很多隻 PHP 同時用 realpath() 的時候效能並不好。

Linux 的 libc 據說沒這個問題 (我沒有實際去 trace libc code,聽別人轉述的),不過實際灌了一台 Debian 跑 PHP 發現解決了 lstat() 的問題後,require_once() 造成的效能問題還是很嚴重。

目前的解法與 Wikia 類似,想辦法讓 require_once() 能夠很快找到 code,不過還是得想辦法從 PHP 本身下手,改善 require_once() 的效能,讓 PHP Framework 發展的時候不用綁手綁腳。

PS:目前的方法是改掉 Zend Framework 裡面的 require_once(),由於我們有一個統一的 /pixnet,把裡面的程式碼全部都用絕對路徑。另外在 Autoload 的部份用 APC cache,避免再到 include_path 內重複尋找。