網站效能分析操作心法 第1回網站效能低落，光找到問題點都要費很多工夫，讓我們先從這裡開始找到真正導致效能低落的關鍵！
從瀏覽器送出欲瀏覽的網址，到整個網頁顯示完畢，中間經過許多設備及服務才能完成，其中所涉及的環節很多：針對網址透過電腦本身設定的DNS主機資訊，連線進行網域名解析查找，找到對應的IP位址，經過一連串的封包路由，其中可能會經過不少網路設備，包括防火牆，負載均衡器，路由器，再連線到網站主機，將HTTP Request送給網站主機上的網站服務程式來處理。
而在網站服務程式收到後，會按該網址所對應的伺服器上的程式碼進行邏輯處理，若有存取資料的需求，則需再透過網路連線至資料庫主機，將對應的資料存取，並將處理完的結果，以HTTP Response方式回應至原瀏覽器，回應的內容會包括HTML、CSS、JavaScript、圖檔、外掛元件（如Flash、Active X、……），再完整呈現在瀏覽器的視窗畫面上。
現在的網頁內容的構成，不見得只會來自一個資料來源，跨網站進行資料交換的現象已經十分常見，內嵌JavaScript程式碼、iframe框架方式，RSS聚合方式，或像部落格貼紙、流量分析的內嵌JavaScript程式碼、廣告版位等，所以同時間一頁的內容，會來自多個網站，必須等到所有相關網站的內容都已反饋完畢，才會完整呈現，故有時會因為其中某個網站的問題，造成整個網頁呈現不順暢。
逐一剖析，找出真正的問題在哪
釐清原因是解決網站效能問題的首要之務。一般而言，會以下列步驟來檢視問題點及縮小問題範圍。
1.先確定案發現場的網路環境狀況
效能異常的現象，有時是因為使用者所處環境，所以須先排除一些基本假設，以免混淆分析方向：
● 在案發現場試著連其他較大型的知名網站（如Yahoo、HiNet等入口網站），看看是否有相同現象? 若是，則應是網路環境之故。
● 利用固網業者（例如HiNet） 提供的連線速率測試網頁，來驗證案發現場的聯外速率。
● 請其他環境的使用者協助檢測，是否有一樣的現象？因為，有時可能是案發現場環境的網路狀況不佳所造成，可請其他的朋友協助確認。而申請不同的固網業者，以及使用不同的頻寬方案，都有可能是造成連線速率差異的原因。
● 是否為無線網路訊號較差之因造成？改接實體網路線後，再觀察是否有一樣的現象？
確認以上問題的同時，可搭配使用一些基本的系統指令來檢視，像是nslookup、ping、traceroute等，進一步確認網路環境是否有明顯問題。透過nslookup可以確認DNS域名查找及解析是否正確；ping可以協助確認從用戶端端到某特定節點之間的封包回應速度，以及傳輸過程中是否有封包丟失的現象；而使用traceroute則可以看出從用戶端到某特定節點之間所經過的所有網路節點之間，傳輸封包所花費的時間分布。
2.確認頁面呈現的瓶項是卡在特定的內容元素上
若網路環境並無疑慮，接下來便是確認使用者端所瀏覽的網頁內容元素的組成。一般而言，會利用瀏覽器內建或外掛的效能分析工具來輔助，常見的像是支援IE的HttpWatch、支援Firefox的Firebug，或是Google Chrome本身的開發人員工具等。
使用這些工具的好處，在於將網頁所有元素逐一分解，以結構化的方式列示出來，便於分析。它讓你清楚看出一個網頁的構成元件有那些，包括下載了的圖片、CSS檔案、JavaScript程式碼、Flash元件等，以及它們在瀏覽器背後建立的網路連線數量，發出至伺服器端請求的數量，傳輸的內容及大小、花費的時間，以及各自傳輸的結果是成功或失敗。
當你透過上述分析工具得到初步結果，接下來，觀察重點可以放在各項請求傳輸時間的消耗。
整個傳輸時間，可大致畫分為Resolving、Connecting、Blocking、Sending、Waiting、Receiving等幾個階段，在這些工具裡，都已經以圖形視覺化方式呈現，方便進行分析：
● Resolving：主要是用戶端花在DNS主機查找及解析域名的時間，一般而言，這部分出問題的機率較低。若有，則可能是用戶端所設定的DNS主機，在域名查找及解析的速度不足。
● Connecting：主要是用戶端到伺服器端成功建立TCP連線的所需時間。當伺服器端忙碌時，用戶端要建立TCP連線的時間就會較久，必須等待其他連線被釋放才能取得。
● Blocking：表示該HTTP Request在用戶端等待被送出的時間，由於一個瀏覽器可同時發出的HTTP Request會有上限值，故當頁面組成元素較多時，部分內容勢必得排隊候傳，待先前送出的Request處理完畢後，才會再陸續送出。
● Sending：為用戶端傳送HTTP Request封包至網站伺服器所花費的時間，與HTTP Request的封包大小有關。影響HTTP Request大小的原因，可能會是GET/POST傳遞參數的數量及內容、Cookie內容，這些訊息可以從工具中，分別針對單一Request查到細節。
● Waiting：為用戶端等待接收到伺服器端送出HTTP Response的時間，這時間會依伺服器端的忙碌程式，以及處理此Request的程式邏輯複雜度有關。一般而言，Request的內容若是靜態資料，相對時間較短；若是動態程式，則花費的時間相對較長。
● Receiving：為用戶端接收HTTP Response所花費的時間，主要與該傳輸的封包量與當時使用之頻寬大小有密切關係，可以對應參照該內容大小，來比對了解其合理性，再來決定是否有辦法優化。
這些階段的花費時間，背後代表著效能問題的可能原因。若起因於網路連線，在Sending、Receiving階段所占時間相對較長；若網站伺服器效能有問題，在Connecting、Waiting耗時會明顯較多。
3.找出可能出問題的徵結
其實很多效能不佳的狀況，查到最後，有很高的比例都是伺服器主機的問題，這時系統監控記錄的機制就十分重要。免費較知名的工具，像是MRTG、RRDtool、Cacti等，商業套件像是WhatsUpGold、PRTG等，都能有效協助分析。
而查看的要點，會針對案發時間點當下，所有主機設備的使用資源來交叉比對。像是伺服器主機或網路設備上的CPU使用率、記憶體使用率，處理程序（Process）數、網路介面頻寬使用量、網路層的TCP連線數、Ping回應時間等。
總之，透過這些數值的觀察，同步檢視既有的組態設定是否還有可調整之處。而調整的方向可以依歷史記錄來推算出合理值，以期能善用系統資源。
例如當網站伺服器的TCP連線數居高不下，而其CPU及記憶體使用率相對較低時，就可以考慮調高該主機的同時最大可連線數設定；當應用伺服器記憶體用量未達實際容量，而造成磁碟I/O量較大時，則可考慮調高應用伺服器的最大記憶體上限值。
4.確認應用服務及程式邏輯執行的合理性
應用程式若有問題，則明顯會賠上不少CPU及記憶體資源，當發現你的主機有這樣的現象，則需對應在上頭執行的程式進行細部檢視。像是多餘的迴圈執行、不必要的變數宣告、使用完畢的物件未釋放，以及對取得資料庫連線的時間點是否恰當等。
這類的問題可利用程式碼檢測工具來快速找出可能的問題，免費的像是Findbugs、PMD， 商業套件像是Fortify。但仍需花較多的時間來修改程式碼。
網站效能問題是網站維運單位持續要面對的，從我建議的上述操作心法來逐一剖析先確認問題點，至少不會在問題發生當下，無所適從。
如同醫院急診室的檢傷單位，必須在第一時間明確定義問題的癥結，有效進行案件分派後送，後續才能對症下藥，一勞永逸。
********************************************* < 網路引用文章***著作權屬於原作者.若不同意分享.請來信當即刻移除***
喜歡本文🔔按讚或分享
沒有留言:
張貼留言