網頁

2012年2月24日 星期五

到底是 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 還是沒辦法解決阿......哀嚎中。