星期日, 8月 31, 2008

funp.com 的 DNS 設定

debug 的時候發現有蠻多人的 blog 頁開起來很慢,看起來是中間某個站台卡住,為了確認問題是我們自己還是外站,拿 HttpFox 出來檢查看看每個 request 的速度,才發現是卡在 funp.com 查不到 IP address。

目前的設定是把 funp.com 的 NS RR 指到 dns{1,2}.funp.com.tw,但又把 funp.com.tw 的 NS RR 指到 dns{1,2}.funp.com... *gosh*

所以邊檢查邊跟 IRC 上的同事聊天,出現以下的對話:
22:33 <@gslin_tfn> funp.com 的 DNS 亂設一通...
22:34 <@gslin_tfn> 害我覺得怎麼 pixnet blog 頁面 load 這麼慢 -_-
22:34 <@gslin_tfn> 誰去抗議一下啊...
22:34 <@gslin_tfn> xxxx_: 那個誰去抗議一下啊
22:34 <@gslin_tfn> xxxx_: 那個誰去抗議一下啊
22:34 <@gslin_tfn> xxxx_: 那個誰去抗議一下啊
22:34 <@far> XDD
22:35 <@gslin_tfn> funp.com NS 指到 funp.com.tw,然後 funp.com.tw 的 NS 指到 funp.com..........
22:35 <@gslin_tfn> 你不要以為現在是七月就會通啊啊啊
22:36 <@repeat> gslin_tfn: 應該是因為不是七月了所以不會通…
22:36 <@gslin_tfn> 啥,不是七月了喔?
22:36 <@repeat> 今天農八月一日。
22:36 <@gslin_tfn> XDDDDDDDDDD
22:36 <@ronnywang> 難怪到今天才不通
補充一下,會不會通是看 DNS implement 有沒有照規矩來,有照規矩來的應該「不會通」XD

在狀態乾淨的情況下要找 funp.com,從 root 找到 dns{1,2}.funp.com.tw 後會再從 root 要 funp.com.tw 的 NS 資料,然後得到 dns{1,2}.funp.com.tw,於是又回到起點,就噴掉了...

各種瀏覽器的支援

IE6 是最麻煩的,有一堆 css workaround 得處理 (像是用 _ 開頭對 IE6 另外計算 css 效果),IE6 本身的 javascript 也有問題,不只是速度,還有對於螢幕、視窗大小的計算。(可以 jQuery 解決一部份問題)

Safari 不要遇到 bug 都很好,遇到的時候就 Orz 了,像是 z-index + select + draggable 似乎很容易中地雷 Orz

Firefox 本身也有好幾個版本要測試,不過畢竟是平常就有在用,自然就會測試到... 像是我自己在家裡用 3.1 w/Tracemonkey,公司會用 3.0 nightly,其他人會用 3.0.x,另外在 Mac 上也有人用 Firefox 3。至於 Firefox 2 用的人就比較少了,不過 repeat 以及 sandy 倒是都還有裝起來用。

Opera 真的沒人用 Orz

Bugzilla 與 Trac

本來內部是用 Bugzilla 在處理 bug (repeat 甚至把整個繁體中文的語言包翻完),不過這個系統實在太複雜... 後來還是換成 Trac,配合一些規定 (Workflow) 在管理,看起來還算可以。

這四天內開了超過四百個 ticket,從官方 blog 上的回報、Ptt Blog 板的回報,以及內部自己測試的回報,現在也只能儘量修。

Anyway,等告一段落再整理一些東西出來。

Subversion

Subversion 1.5 後終於有存 merge history,不再需要自己計算 merge 的部份。不過目前的版本問題還是不少 (目前是 1.5.1),使得使用起來還是綁手綁腳的。

一個常見的情況是錯誤的 commit:有些 developer 會把非 branch only 的修改直接 commit 到 branch 裡 (就別問為什麼會這樣了),這時候一個簡單的作法是把這個 commit merge 回 trunk。但這樣會造成 Subversion 之後要再從 trunk merge 到 branch 時混亂。目前的解法是在 trunk 再 commit 一次,然後故意 merge trunk to branch 造成 conflict,然後把他解掉。

不過這陣子開始在研究 Mercurial 了,因為 Mercurial 也有 centerialized pattern 可以中央集中管理,目前已經測的差不多,只要把 Subversion 的 post-commit 都移植過去就可以了。

require_once 的效能

因為這是 PHP 的問題 (而且看起來 PHP 5.2 系列沒解),我在 Zend Framework 的 mailing 上有問關於 ZF 有沒有避免的方法:require_once performance issue in ZF

其中第一篇回應指出既然都用 autoload,那麼就拿掉所有的 require_once,應該可以解決我的問題,我測了一下,似乎有幫助,但沒有想像中那麼多。看起來還是得仔細調整 include_path 以避免大量的 lstat miss。

第二篇回應基本上是個搞不清楚狀況的人問一些狀況外的問題。要裝一套有 opcode cache 的軟體已經是常識了,另外整個問題在於 system call,而非 I/O bound,要人丟到 memory disk 上面沒有意義。

不管怎麼樣,以目前的效率來說,還是得不斷的試著調整系統,17 台 PHP server 感覺還是太多,希望可以壓到 10 台左右。

本次升級有感

當你想用 dirty hack 儘快解決事情,之後一定會遇到 bug,然後花更多的時間解決。

不過有更多的人不懂這一點,仍然不會學到教訓。