http://blog.gslin.org 幹壞事是進步最大的原動力 Sat, 06 Sep 2008 08:44:04 +0000 http://backend.userland.com/rss092 en 這個週末大概要大亂了... 剛剛發現系統異常，一路追查下去發現國內 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 ... http://blog.gslin.org/archives/2008/09/06/1677/ 最近在研究頁面速度時想到的方法，這個方法對於之後的 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 速度實在是不怎麼樣... http://blog.gslin.org/archives/2008/09/06/1667/ 剛剛在 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 這篇提到的問題。 http://blog.gslin.org/archives/2008/09/03/1662/ 在 GetClicky Analytics Service Tracking 2% Google Chrome Usage 這篇文章看到 GetClicky 在 45000 個網站即時統計 (實際上是 15 mins) 出來的結果。 目前我看到的是 1.91400% (reload 後變成 1.87233%... XD)，應該會繼續往下跌，不過不知道會跌到什麼地方。 Update：現在是 2.78387% 了... @_@ http://blog.gslin.org/archives/2008/09/03/1659/ 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 設定則是直接吃 ... http://blog.gslin.org/archives/2008/09/02/1648/ 在找 blog 開起來很慢的原因時發現的，全文在這邊：funp.com 的 DNS 設定。 然後我剛剛才知道原來七月過了啊... http://blog.gslin.org/archives/2008/08/31/1646/ 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() ... http://blog.gslin.org/archives/2008/08/29/1639/ Amazon EC2 一直都沒有保證在上面的磁碟資料不會掉，這使得 MySQL 必須透過定時備份到 S3 以及即時將 binlog 備份到非 Amazon 的站台以確保資料的安全性。 之前的解法是將資料放到 Amazon SimpleDB 上，但 SimpleDB 的空間有限制 (還在 limited beta)，而且會有被綁在 Amazon 上，如果想要搬出來會找不到 open source 的替代方案。另外一個問題是熟悉度的問題，大家還是比較偏好用 MySQL 這類的 RDBMS。 這個限制終於在 Amazon 推出 EBS (Elastic Block Store) 解決了：你可以在 EC2 上開一個磁碟空間給 MySQL 用！ 這個空間確保資料的持久性外，還可以 snaphost 到 S3 上。第一次 snapshot 會是 full backup，後面都是 incremental backup。單一 EBS 的空間可以從 ... http://blog.gslin.org/archives/2008/08/21/1632/ 這篇會講怎麼在 FreeBSD 上建立標題所說的環境。 Apache 2.2 的部份，透過 ports 編譯時加上 WITH_MPM=worker 即可： # cd /usr/ports/www/apache22 # make WITH_MPM=worker install clean 裝好後將 /usr/local/etc/apache22/httpd.conf 裡 httpd-mpm.conf 前面的 # 拿掉，並修改 /usr/local/etc/apache22/extra/httpd-mpm.conf 內 mpm_worker_module 那段： ThreadLimit 512 StartServers 1 MaxClients 512 MinSpareThreads 1 MaxSpareThreads 512 ThreadsPerChild 512 MaxRequestsPerChild 0 這些數字的設計是故意只跑起一隻 httpd，負責所有的連線。 再來是裝 mod_fastcgi： # cd /usr/ports/www/mod_fastcgi # make install clean 到 /usr/local/etc/apache22/httpd.conf 裡把 fastcgi_module 的註解拿掉後，把設定檔放到 /usr/local/etc/apache22/Includes/fastcgi.conf 裡： # FastCgiConfig -maxClassProcesses 1 ScriptAlias /fcgi-bin/ "/usr/local/www/fcgi-bin/" <Directory /usr/local/www/fcgi-bin/> ... http://blog.gslin.org/archives/2008/08/17/1624/ YUI team 終於想開了，不再用像是 YAHOO.util.Event.addListener 這種寫 code 時會一直抱怨的命名方式，而是改用 Y 當作物件，並支援 fluent interface，也就是 Y.foo('blah').bar('blah2') 這種串接的用法：YUI 3.0 Preview Release 1。 但缺點就是因為語法改變，你必須改寫... 不過應該不是大問題，因為 YUI 2 與 YUI 3 不衝突，在過渡期時你可以把兩個 framework 都讀進來。 http://blog.gslin.org/archives/2008/08/14/1621/