2013年12月19日 星期四

網站效能不佳?談『如何判定系統變慢原因』的簡易 SOP


        上次『大禹治水』提到,對於採用 Windows+ASP.NET+MSSQL 技術的網站服務,找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手,減少無頭蒼蠅盲目亂撞的時間成本浪費,這篇就簡單介紹一下這簡易的 SOP。

        符合“簡易”的這個特徵有兩個條件:
  1. 不用額外安裝任何第三方軟件或工具,只使用作業系統內建的基本工具即可。
  2. 與系統特性無關,不需要先理解遇到麻煩的系統任何內部原理與商業邏輯。
        所以任何任何人,都可依照這個 SOP,花個半天時間迅速判斷 80% 以上的網站效能瓶頸點。


        首先,當網站系統總是不太回應時,相信剛開始大家會做的第一步應該都一樣:打開『工作管理員(TaskManager)』看一下 CPU / RAM 的使用狀況


        如果 CPU 或是記憶體使用率偏高總是在 90% 往 100% 天花板上撞,就要看是機器上的哪支程式吃掉,對於多使用者的網站系統,通常不外乎是網站服務(IIS - w3wp.exe)或是資料庫服務(SQL Server - sqlservr.exe),若是其他非必要程式吃光了 CPU ,例如防毒軟體,就要請 MIS 妥善設定這類軟體或是直接關閉,這一樣可以透過工作管理員就輕鬆找到。


        最好多加入一些欄位輔助判斷,例如 PID 和執行緒數量,尤其如果你的網站內有許多子功能網站,且使用 IIS 應用程式集區而有多個 Worker Process,會需要 PID 幫你分辨是哪個子功能的網站過度忙碌,而不需要依靠個別關閉來 try 出哪一個是占用資源的子網站。

        如果 CPU 看來平靜無波,有可能是對外的網路頻寬出了問題,塞車是塞在外面。簡易的判定方式是直接在網站伺服器上打開瀏覽器觀看自己的網站,如果非常通順,那就是對外網路頻寬的問題,從外部 ping 一下回應數據(有些可能關閉不給 ping),然後打電話給機房人員吧。

        若不是網路問題,不論 CPU 使用率高不高,即使從伺服器上看網站都非常慢,這時候就需要透過『效能監視器(Performance Monitor)』來觀看網站服務實際的狀況。下圖是我前一陣子幫公司做壓力承載測試所截下的圖片:

一開始流量還沒灌進來時...


        上圖可以看出,不間斷地同時間有 100 個請求(Request Current),來跟網站要資料。每個請求大約會卡住三秒之後才會回應(Request Execution Time),說明了這時候如果有使用者連上網站,大約要等三秒之後才會開始看到網頁回傳。

        不過以我的例子,用戶會卡三秒,但是右邊卻顯示 CPU 閒置到不行,幾乎沒在做事。原因是因為瓶頸卡在後端的資料庫主機上:

16 核 80G RAM 的機器被我操爆了

        請注意,我上面又特別把“死結”的計數器打開Number of Deadlocks)。這個數字如果出現,往往會造成 CPU 使用率偏低(因為都在空等不做事),但是系統會卡很久不做事,光從『工作管理員』這樣的基本工具會找不出效能瓶頸。遇到 Deadlock ,是需要修改程式邏輯去解決的

        如果不管資料庫或是網站服務都看不出 CPU 使用率飆高的現象,也沒有 Deadlock,但是 Request Execution Time 卻莫名其妙地拖高,不要多想,一定有 BUG 造成執行緒等待某個外部訊號或資源而 Blocking!工程師快認命去修程式吧(案例)!

        是不是被攻擊或是不當使用,差不多在這個步驟已經可以看出來。根據 Requests Current 數量是否異常地高,要找出被重度利用的點是哪裡,只要開啟 IIS 本身的紀錄即可


        這個紀錄檔內會記載對方要求的網址,瀏覽器,作業系統這些 HTTP Header 內會有的東西,經過整理,很快就可以統計出最頻繁被索取的網址路徑,頻率最高的來源 IP,做為進一步反制的參考依據。

        以上基本款的 SOP 大概半天到一天的時間就可以釐清 80% 常見的網站效能問題,剩下 20% 屬於系統開發設計不良造成的瓶頸,屬於更進階個案的問題,但是透過額外的工具輔助依然可以找出癥結點,不過這就不符合“人人可做的簡易精神”了

        今年 50 篇的部落格文章在這篇達成!祝福大家新的一年,系統都可以頭好壯壯,不用依賴乖乖也能過個好年!

Google+ Badge