上次『大禹治水』提到，對於採用 Windows＋ASP.NET＋MSSQL 技術的網站服務，找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手，減少無頭蒼蠅盲目亂撞的時間成本浪費，這篇就簡單介紹一下這簡易的 SOP。
符合“簡易”的這個特徵有兩個條件：
- 不用額外安裝任何第三方軟件或工具，只使用作業系統內建的基本工具即可。
- 與系統特性無關，不需要先理解遇到麻煩的系統任何內部原理與商業邏輯。
首先，當網站系統總是不太回應時，相信剛開始大家會做的第一步應該都一樣：打開『工作管理員（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 篇的部落格文章在這篇達成！祝福大家新的一年，系統都可以頭好壯壯，不用依賴乖乖也能過個好年！
沒有留言:
張貼留言