快速揪出網站效能不佳的罪魁禍首

從瀏覽器送出欲瀏覽的網址，到整個網頁顯示完畢，中間經過許多設備及服務才能完成，其中所涉及的環節很多：針對網址透過電腦本身設定的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。但仍需花較多的時間來修改程式碼。

網站效能問題是網站維運單位持續要面對的，從我建議的上述操作心法來逐一剖析先確認問題點，至少不會在問題發生當下，無所適從。

如同醫院急診室的檢傷單位，必須在第一時間明確定義問題的癥結，有效進行案件分派後送，後續才能對症下藥，一勞永逸。

作者簡介

陳宏一

目前於一家網購平臺公司擔任技術經理，交通大學資訊管理研究所碩士，專精於OOAD、J2EE相關技術、Open Source、資料庫設計、軟體開發流程及專案管理等；取得SCJP、SCWCD、SCJD、SCEA、ITIL等認證。曾經歷大型社群及電子商務網站、WAP/3G行動加值服務、CTI/CRM客服系統架構規畫設計等。