性能問題的分析定位方法
之前寫過一篇性能測試新手誤區(qū)(五):這是性能問題么,主要講一個有效的性能問題應(yīng)該是什么樣的,其中提到了定位的問題。但是那篇文章只說了WHAT,并沒有說HOW,只說tester要有明確的定位,卻沒提如何才能定位。實際工作中,我也總是接到這種問題,所以還是要寫一篇關(guān)于方法的文章,來說說HOW TO DO。
以一個典型的WEB系統(tǒng)來舉例,性能問題一般體現(xiàn)在客戶端請求后的響應(yīng)時間上。在性能測試過程中,即壓力增大到某個程度后,響應(yīng)時間指標(biāo)迅速增長。但如那篇文章所說,這只能叫做一個現(xiàn)象,測試人員需要找到問題所在,HOW TO DO?
首先要搞清楚,客戶端從發(fā)出請求直到看到最終結(jié)果,共經(jīng)歷了哪些過程。如果繪制出一張完整的路徑圖,我們的問題必將定位到這張圖中的某一點上。下面是我畫的一個常見的WEB系統(tǒng)請求的流轉(zhuǎn)過程。
客戶發(fā)出一個請求,這個請求首先會到達(dá)中間件的監(jiān)聽端口,專門的監(jiān)聽線程負(fù)責(zé)接待它,并將它分配給一個空閑的HTTP處理線程。HTTP線程根據(jù)請求內(nèi)容,去執(zhí)行相應(yīng)的程序代碼,這里會涉及程序的內(nèi)部資源,比如專用的線程、一些隊列等,程序的內(nèi)部也許還有多個組件,依然可以拆分。再往后,從中間件維護的數(shù)據(jù)庫連接池中取出一個空閑連接,通過它來與數(shù)據(jù)庫進行交互。數(shù)據(jù)庫收到查詢請求后,同樣需要找到一個可用的執(zhí)行線程,然后才能執(zhí)行具體的SQL,這里又會牽扯到很多數(shù)據(jù)庫的內(nèi)部資源,如鎖、緩存等等。
可以看到,從用戶點擊鼠標(biāo)發(fā)出請求,到顯示器上展現(xiàn)出結(jié)果,實際是經(jīng)過了很多處理過程的,這里的每一個節(jié)點出現(xiàn)問題,都會導(dǎo)致我們最終看到的“響應(yīng)慢”現(xiàn)象出現(xiàn)(這里不考慮操作系統(tǒng)層面、網(wǎng)絡(luò)層面等一些外層的因素)。
理解了這個過程,只需采取一些科學(xué)的方法即可逐漸逼近問題根源,那就是層層剝離、不斷排除。從實際經(jīng)驗來看,數(shù)據(jù)庫端最容易出問題,那么首先就要對其進行驗證。數(shù)據(jù)庫的性能一般是直接體現(xiàn)在SQL的執(zhí)行效率上,我們可以捕獲到出現(xiàn)問題時所有執(zhí)行過的SQL,看其耗時是否正常。如果判斷數(shù)據(jù)庫端沒有問題,那么再來到中間件端,這里又可分為應(yīng)用服務(wù)器本身和我們自己的程序,可以先看看最容易驗證的部分,應(yīng)用服務(wù)器本身通常維護了一些線程池,很容易可以觀察到它們的使用情況,如果這里沒有發(fā)現(xiàn)異常,那么問題很可能就出現(xiàn)在我們程序的代碼內(nèi)部。如果在某一點上發(fā)現(xiàn)了異常現(xiàn)象,不要急于斷定這里就是問題根源,而是要同時觀察與之相鄰節(jié)點的表現(xiàn),一個節(jié)點的故障通常也會導(dǎo)致另一節(jié)點的異常。
一個很有效的排查手段就是日志,在每一個節(jié)點上輸出接收到的請求和處理結(jié)果的日志,通常都會很容易的發(fā)現(xiàn)問題。
大致思路就是這樣,總結(jié)起來其實很簡單。一是要理解請求處理的完整流程,二是通過科學(xué)合理的方法去分析。
最后推薦個比較典型的問題排查過程供大家體會,超級奇怪的“黑色10秒鐘”。我自己也有一些這種很有代表性的分析過程,有時間整理好也貼上來。
posted on 2013-06-09 11:50 順其自然EVO 閱讀(319) 評論(0) 編輯 收藏 所屬分類: 性能測試