放假

兩件雜事...

因為這個禮拜以及上個禮拜都在衝簽呈的進度,星期二總算是告一段落,星期四利用十六個小時的睡眠暫時舒緩了一些疲勞...

另外一件事情是 Layeredtech 有特價,而且還可以再用 payment 打折:$99/month 的 P4-2.8GHz + 2GB/RAM + 500GB/HD + 100Mbps Uplink + 1500GB/Bandwidth$115 的 P4-3.4GHz + 與前面一樣的條件。信件裡提到了很多,有需要的人我再 forward...

#bsdchat 搬到 freenode 上,換 UTF-8 編碼

紀錄一下情況:(2/24)

12:12 <@chinsan_> http://doxory.com/choice/1813 #bsdchat 要不要從 IRCNET 改搬到 freenode?
12:12 <@chinsan_> 要表決看看嗎?
12:13 <@mjhsieh> 順便改成 utf8? # 推廣 utf8...
12:14 <@chinsan_> hmmm...
12:14 <@in2> 果真這種服務完全沒有忠誠度可言 XD
12:17 < PipperL> 忠誠度又沒有專屬頻寬 XD
12:18 <@chinsan_> 忠誠度又沒有專屬小島 XD
12:37 <@yinjieh> 搬吧 不過到時候就不能這樣 OP 狂發了 (?)
12:39 <@gslin_cs> yinjieh: 沒什麼不可以的啊 XD
12:43 <@yinjieh> gslin_cs: 報告是!XD
12:43 <@yinjieh> 那就馬上搬 (?)
12:45 <@yinjieh> 只有我投票啊?XD
12:45 <@yinjieh> 話說有人已經搬過去了嗎
12:45 <@hcchien> 那我也要
12:45 <@gslin_cs> 我剛剛加進去發現有人註冊過了?
12:45 <@gslin_cs> UTF-8 對吧
12:46 <@gslin_cs> 搬過去順便換
12:46 <@hcchien> 投搬家 + utf 一票
12:46 <@sharity> gogogomoving
12:46 * sharity (CS-ing)

Zend Framework 中,Zend_Controller 測試時遇到的問題

我有三天的時間卡在 Zend_Controller 的使用問題,不管怎麼用都會丟出 500 Internal Server Error。後來不斷的測試,發現他根本就會動,只是我測試的方法有問題。

先講一下 Zend_Controller 的用法,在引入 Zend_Controller_Front class 後 (方法請參考官方網站的說明):

  • 先用 $ctrl = Zend_Controller_Front::getInstance(); 取得 controller。(跟 I HAVE CONTROL 無關... 看不懂笑點的請參考 CLANNAD 00)
  • $ctrl->setParam('noViewRenderer', TRUE); 將預設啟用的 Renderer Helper 閹掉。
  • 然後用 $ctrl->addControllerDirectory('目錄位置'); 設定 Controller 目錄。
  • 最後用 $ctrl->dispatch(); 開始跑。

然後 controller 的目錄下放 IndexController.php 就會對應 http://host/index 以及 http://host/ (因為 index 是特殊的存在),放 TestController.php 就會對應 http://host/test,這些在官方文件裡都有還算清楚的範例。

我的錯誤是在,我錯誤的使用 GET 的 proxy 模擬 HTTP Request。簡單的說,以下的 HTTP Request 會造成 500:

GET http://test.host.domain/test HTTP/1.1
Host: test.host.domain

但這個不會:

GET /test HTTP/1.1
Host: test.host.domain

而我用 libwww-perl 內附的 GET 這個「指令」測試:

GET -SUe -p http://test.host.domain:80/ http://test.host.domain/test

這個指令會送出第一類 HTTP Request,於是就噴了... 就只是這樣的問題而已。

Zend Framework 的一些設定上的想法

開始使用 Zend Framework 後,一些設定上的想法。

首先是 Zend Framework 的引入設定,有些文章會建議放到 php.ini 裡,在 include_path 引入,但我認為比較好的方式是在 index.php 裡引入:

set_include_path(get_include_path() . ':' . dirname(__FILE__) . '/../weblib/ZendFramework-1.5.0PR/library');

如果大家都共用系統的 library,那麼在升級時很有可能會中獎。至於這個指令對於系統效率的部份,我覺得這個東西差不了多少,不需要對此計較,先把時間花在其他地方比較好。

再來是 .htaccess 的部份,Zend 的文件上建議把 css/js 之類的靜態圖檔設定到 Regular Expression 裡分開,我的建議是全部都丟給 index.php,然後靜態圖檔用另外一個 domain 放:

#
RewriteEngine On
RewriteBase /~gslin/zendtest
RewriteRule .* index.php [L]

原因是一開始先稍微規劃,先用一台機器跑 VirtualHost 服務兩個 domain,之後長大了才容易拆開。當靜態圖檔的量大到會影響動態的部份時,抽出來用 lighttpd 吐。

然後,既然都用了 Framework 這種東西,APC 之類的 opcode accelerator 一定要裝,不然速度會很慢。另外 APC 預設 30MB 的 cache 可能會不夠用,調大一點會比較好。

Apache 一定要用 FastCGIPHP 抽出來跑,不要用 mod_php5 的模式跑。這樣 Apache 就可以用 event 或是其他 threading MPM 執行,對於效率會有很大的改善,我在去年年底有寫過:Apache 2.2 的 MPM Event

基本上效率不要太斤斤計較,因為很有機會一個 SQL slow query 的改善,就可以大幅度改善整體的效率。現在一台看起來還算暴力的 x86-64 1U 伺服器不用 100k 就有一台 (雙四核心 Xeon 加上 12GB RAM 與 SCSI*2),把人力時間花在開發上面比較實際...

MySQL 在創見 SSD 上跑的情況

最近進了四顆創見 SSD MLC 顆粒 32GB 硬碟 (連結應該沒錯) 跑 RAID 1+0,就讓 jnlinDebian 上跑 MySQL 5.1 測試 MyISAM 的效率,測試的結果相當慘,寫入的速度在個位數 qps (對... <10 query per second),而且不是模擬資料,是 Real Data 的 Replication Update...

測過的 Filesystem 包括 ext3XFS,block size 也調整過好幾次,RAID 1+0 的部份是軟體做,這部份的 block size 也調整過,不過不管怎麼測,速度都還是上不去。

Mtron SSD 硬碟還沒有開始在台灣代理之前,用一堆 RAM 加上 15K RPM SCSI 硬碟做 RAID 1+0 比較便宜,而且也比較穩定...

Update:我要求 jnlin 將測試的想法丟到網頁上,現在可以在他的 blog 上看到了:「MySQL 在創見 SSD 上的測試」。

Zend Framework

這幾天除了在寫簽呈外,其他大多數的時間都在玩 Zend Framework

Zend Framework 與其他的 Framework 有個很大的地方不同,他所有的套件都是可以拆開來用的,也因為如此,有許多人覺得 Zend Framework 其實只是另外一套 PEAR 而提出批評。不過我後來對於這些想法看的比較開了,只要會抓貓的都是好老鼠... (XD)

文件如同 PHP 的慣例都蠻齊全的,在文件裡就有很多 sample code,大多數測試一下就可以用了。

不過我自己在測 Zend_Controller 的時候卡住,用了三天時間還是解決不了,最終在學弟給的 sample code 比較後找到問題,希望以後開發速度可以快很多...

memcachedb

memcachedb 是以 Berkeley DB 為 backend 的 memcached-compatible server。

memcached 一開始是 LiveJournal 以大量的 memory 作為 cache 加速用。除了 Perl 本身外,後來在各平台上都有對應的 library 可以用,而且也被證實他的效果很棒,Facebook 甚至弄了兩百台 16GB 的機器來跑 memcached。

最初的版本有一些架構上的問題,像是最原始的 memcached 是先計算 key 的 CRC32,再算餘數而決定是哪一台機器。這使得新增或移除機器時,會造成整個 cache 大洗牌,後來引入 Consistent Hashing 後就解決了,而且 Consistent Hashing 的觀念並不難懂,很多 memcached client library 都有實做。

另外是 cache server 重開後會因為要重新計算,會有一段時間網站變慢,Wikipedia 裡有人試著改了一個以 Berkeley DB 為底層的版本,後來不知道什麼原因又改回 memcached 了。

現在這個 memcachedb 是以 Berkeley DB 4.6 為基礎,利用 BDB 提供的 Replication 提供高可靠度,並想辦法維持相同的效能。另外,因為使用 Berkeley DB,所以 disk 也被當作 storage,也希望可以利用更大的空間提高 cache hitrate。

不過有些地雷還是要注意,如果有要使用的人,應該要訂 mailing list 看上面的討論。目前最常遇到的地雷是可以接受的 key 與 value 的長度異常的小,我在 porting 0.0.x 版到 FreeBSD ports 時有把 key 修正到 128bytes (原來是 16bytes),不過這點在 1.0.0 beta 應該修掉了,因為我在更新時翻過 header file,裡面沒有再看到這個限制,不過使用上可能還是要注意一下。

另外 memcached 原作者 Brad Fitzpatrick 似乎對於 Berkeley DB 版本的效率感到好奇,有跟 memcachedb 的原作者討論一些架構上的想法,也許這兩位會擦出什麼火花...

新的 GPL 字型:文泉驛正黑

又多了一套字型可以用了:文泉驿开源矢量中文字体,包括了 GB2312、Big5,以及日韓文,以 GPL 發行。(請注意,關於 GPL Fonts 的問題請參考 How does the GPL apply to fonts?)

不過有些字在放大後可以看出來字體基線沒有對齊 (像是「驛正黑」這三個字),這點就比較沒辦法了。下面是文泉驛正黑的字型配合 GDI++ 的情況:

BitTorrent 補 Obfuscation 的不足

TorrentFreak 看到的,BitTorrent 的研發團隊決定要把某個洞補起來:BitTorrent Developers Introduce Comcast Busting Encryption

一開始 BitTorrent 是以 Port 號碼的方式避開管制,但很多人都學會跳號碼後久沒用了 (甚至有些軟體支援啟動時隨機選號碼),接下來就進入 Content Filtering 的階段,一開始是透過 BitTorrent 連線一開始的 handshake pattern 管制,後來 Obfuscation 一出來後就失效了,最近是透過 client 與 tracker 的 HTTP 資訊過濾,而這個洞一直到最近,才被 BitTorrent 團隊提出改善方法:Tracker Peer Obfuscation

這個新的方法是讓軟體與 tracker 連線時所傳輸的 IP/port 資訊也加密,避免過濾的設備利用這些資訊。其中會以 infohash 當 shared secret,並加上一些處理後產生 RC4 key 加密。

剩下的方法剩正向表列 Content Filtering 的方式,然後看情況走向 SSL-compatible...

美國的法院判決上網公開查詢

Tim O'Reilly 在他的 Blog 上提到,自 1950 年開始美國最高法院的判決電子資料上網,讓人公開使用:Court Decisions Online

台灣也已經做一陣子了,司法院的「司法院法學資料全文檢索資料開放範圍」可以看到有哪些資料已經可以在網站上找,比較常用的兩個:判決書查詢簡易案件查詢。當然,不要忘記全國法規資料庫