到底是 programmer 還是雜耍工

有感：程式設計師在除錯的時候就像偵探一樣，必須鉅細靡遺的抽絲剝繭。

這一個禮拜幾乎都在做偵探在做的事情。起因是有個 flash 在測試環境連 amfPhp 的 Server 測試起來都沒啥問題，一到線上環境就會莫名其妙的亂卡。卡的時間還很詭異的都是五的倍數。

於是第一個當然就是懷疑線上跟開發環境的版本問題啦。
所以一開始就把 lighttpd 版本，換呀換， php 版本換呀換，結果問題還是存在。

那不然應該就是，線上的 load 過高？可是圖表看起來一切都還好阿。於是一連串由可能懷疑的都懷疑了。先是懷疑 fastcgi process spawn 的速度，然後又懷疑是不是 fastcgi handler，所以也換了好幾種 fastcgi 的模式，也用了 php內建的 php-fpm ，結果依然照舊。

後來發現這個恐怖的 amfphp 竟然會一直抽插 lighttpd ，每個 rpc call 都要 connect 一次，於是開始覺得會不會是 lighttpd 的 fastcgi handler 不夠力，會 queue 住，之後發現也不是，然後又開始懷疑該不會是 socket 有問題吧.....。

到最後能調的都調過了，其他網頁的速度也明顯的加快許多，可是還是一樣，莫名其妙會卡。

好吧，那應該不是 server 的問題了，乖乖的抽絲剝繭看看吧。

所以就乖乖的進 php 裡面用，「夾擠法」去找出到底卡在哪。最後發現卡在兩個點，一個是在 amfphp 的 auth 模組，一個是在 class 模組。

trace 進 auth 模組裡面發現裡面有用到 session ，不會吧，難道這種流量 io 就撐不住了嗎？於是把 php 的 session 丟到 ramdisk ，情況依舊。後來找到 session 相關的問題有人提到session lock 要注意。 我也乖乖的改了，還是一樣。

後來跟 clark 討論的時候他看了看程式碼，蹦了一句話，那應該是每次用完 session 就先強制 close 掉就好。於是我又乖乖跑回去改 code ，結果還是卡。就當一籌莫展的時候無意間看到，咦？auth 模組真的不會卡了耶！所以 session lock 莫名的就被修好了。到這裡已經用了三天。

之後又繼續 trace class 模組，到最後發現產生的地方在 new 物件的地方花費很久，這就束手無策百思不得其解了好一陣子。不會要我對線上環境 gdb 吧？這根本沒搞頭阿。不小心被我找到一個東西：http://xdebug.org/，這東西真是太銷魂了阿。

一丟進去，就算是線上環境也還好，馬上就可以看到是卡在哪裡。

class 模組馬上看到是在兩個點，跑進去追根究柢後，一個是 pear 的問題，一個卡在 mysqli 的 connect ，一量馬上發現，原來問題是出在 mysql slave ，都顧著調 master ，結果是 slave 的 connect 有時候會卡。

還好，找到問題，收工。

但是那堆 pear 還是沒辦法解決阿......哀嚎中。