最近這兩天因為【內政部::不動產交易實價查詢服務網】網站上線而引起網友熱烈討論，雖然批評聲浪非常大，但我並不是要來數落這個網站的缺點，而是希望透過這個案例告訴大家網站壓力測試的重要性，尤其網站是那種可預期的大流量到來，網站建置廠商或客戶更應該提前做好準備，以確保網站能在預估的標準下正常運作。我相信，沒有人會反對網站上線前要做壓力測試，但我多年經驗下來發現，雖然手邊壓測工具都有，但普遍的問題是不知道怎樣測試？不知道測試的重點在哪？不知道壓測標準怎樣界定？不知道壓測報告怎樣閱讀與分析？今天想透過這篇文章來分享我在實務上進行網站壓力測試的經驗。
網站壓力測試相關的技術領域
因為網站壓力測試牽涉的範圍非常廣泛，並不是非常容易進行，也因為牽扯到的知識領域很廣，所以真正能確實做好壓力測試的人並不多。其中可能牽涉到的技術領域有：
- 設備管理
- 壓力測試必須使用專屬的電腦設備，盡量不要使用 VM (虛擬機器) 實施壓力測試，這樣才能真正模擬出較為真實的壓力測試數據。
- 要實施專業的網站壓力測試，應該會有以下設備要事先準備：
- 受測系統主機：對於要被施加壓力的主機
- 測試控制器主機：由控制器主機發動測試並收集壓力測試過程中所有數據
- 測試代理程式主機：由多台測試代理程式主機實際發動測試，對受測系統施加壓力
- 網路交換器(Switch)：在負載平衡的網站架構下可能需要網管型 Switch 的設備支援
- 負載平衡器(Load Balancer)：測試過程可能會用到硬體式的負載平衡器設備
- 防火牆設備(Firewall)：測試過程可能會需要測試出防火牆設備的吞吐量(Throughput)
- 系統管理 / 網路管理
- 在一個完整的測試環境下，需要事先準備的工作非常多，可能包括的規劃項目有：
- 受測環境網路規劃
- 進行壓力測試時，建議排除「網路」可能造成的任何影響，也就是不要將受測主機擺在遠端，最好是將壓測主機與受測主機都擺在同一個區域網路(LAN)裡來測試，因為我們主要測試的是受測主機實際吞吐量，加入了網路變數後壓力數據就會嚴重失真，那麼這份報告的精確度也不會高。
- 是否要設置一個獨立的 IP 網段做壓力測試？
建議盡量用獨立網段作業，不要跟公司內網正在用的網段來測試，不然可能會影響公司其他同仁的網路運作。
- 透過負載平衡器做壓測可能會受到 IP 來源的影響而導致負載不夠均衡，因此建議可用多個 IP 同時進行壓測，這功能在 Visual Studio 2010 Ultimate 裡找的到。
- AD 環境建置
- 由於必須模擬出生產環境(Production Environment)的部署架構，所以很有可能需要建置一個壓力測試用的 AD 環境。
- IIS 網站伺服器調校
- 網站部署後必須調校 IIS 設定以調出最佳性能，所以在壓力測試的過程中可能要不斷微調 IIS 伺服器的設定。
- 壓力測試軟體安裝與設定
- 壓力測試種類繁多，且設計邏輯不同，所以要選對產品進行壓測才對。
- 網站負載平衡環境架設
- 測試過程可能會用到硬體式的負載平衡器設備或是微軟 Windows 伺服器內建的 NLB (Network Load Balance) 服務，這些都需要進行設定與調整。
- 網路交換器(Switch)管理與設定
- 建議使用網管型網路交換器，因為像是 NLB 這類的網路負載平衡服務可能需要依賴 Switch 設備提供的 IGMP Snooping 功能來設定 Multicast 相關參數。參考資料: 精通 NLB：單點傳播(Unicast) 與 多點傳送(Multicast) 的差異
- 除此之外，當流量超過 GbE 等級的話，可能要換成 10GbE 的網路交換器，或是使用 Trunk 方式合併多個 Ports 的流量，以增加主機可負荷的流量。
- 防火牆設定與負載分析
- 我在實務上偶爾會看到有客戶做了壓力測試，卻在上線後掛在防火牆設備，因為防火牆等級無法應付大量的用戶端連線 (Sessions) 而導致防火牆過於忙碌，反而影響的網站的效能表現。因此當防火牆加入壓力測試的範疇後，應該要進一步分析在壓力測試的進行中防火牆的性能表現，如 CPU, Memory, Connections, Sessions 等各種數據表現。
- 網路流量監控與報表
- 測試過程中最好使用 GbE 等級的網路設備進行測試，如果預期流量會超過 GbE 等級的話，也必須進一步監控流經這些設備的流量，你可安裝 Cacti 或 MRTG 進行流量監控，也可自行收取設備的 SNMP 封包進行分析。
- 壓測工具
- 能夠實施網站壓力測試的工具非常多，從組合屋到豪宅等級的都有，當然你選用「豪宅」等級的壓測工具價格可能也不太便宜。在此我列出一些常聽到的壓力測試工具如下：
- 前端程式開發與調校
- 後端程式開發與調校
- 說實在的，後端程式的效能調校也是五花八門，只能考實戰累積出經驗才能真正上手，不過最基本就是做好完善的快取策略。
- 資料庫管理與調校
- 壓力測試的過程中，通常會與資料庫系統息息相關，如果網站沒有妥善規劃快取策略，只要在高壓之下很快就能看出你的資料庫系統負載過高，這時就必須要對資料庫做出適當的調校，例如遺漏索引分析、資料庫死結監控、資料庫封鎖監控、交易紀錄檔變化、…等等。
也因為進行壓力測試可以測出非常多原本不會發現的問題，因此所有相關的技術知識也必須具備才能真正調好網站效能。
網站壓力測試，到底測的是什麼？
在進行網站壓力測試時，最重要的是先搞清楚「目標」是什麼？你可能會想，不就是測「壓力」嗎？給他超大壓力，然後讓網站掛掉，就知道能承受多少壓力了嗎？
事實上，網站壓力測試不僅要知道系統的耐壓程度，另外還有一個很重要的測試標的是「網站穩定性」。
我們公司前幾天就正在對一個客戶的網站做壓力測試，因為這次網站從去年就已經上線，同樣的程式在去年已經進行過壓力測試，也非常順利的通過同時數千人連線的考驗，今年客戶委託我們做出一些功能調整並改版上線，在上線之前我們又再次進行壓力測試，這次不一樣的是，雖然壓力測試都通過驗證，數據也很漂亮，不過當我們以同時上線人數 1,500 人的情況下連續測試 10 分鐘，就在第 6 分鐘時開始發生程式錯誤，有時找不到網頁、有時引發 HTTP 500 Server Error 錯誤，非常的詭異，經程式開發人員的調整下發現原來是 web.config 沒有設定正確的 <machineKey> 導致壓測過程的狀態在一段時間後引發資料同步問題，這並不是單純測試壓力就能看的出來的，「時間」也是一個非常重要的穩定性因子。
除此之外，網站壓力測試還需要訂定出性能指標，當然客戶可以用他們自己的角度來定義，但網站的人數多寡並不是用「喊」的，你還是必須先透過實際的數據進行分析，分析出網站在最尖峰的時刻有多少人上線，網站伺服器有多少同時的連線與要求，最長的回應時間有多少，這些都必須從各個設備收集數據並分析瞭解後才能做出判斷，否則盲目的定義壓測目標，只會讓事情難以進行而已。
另一種常見的情況是，客戶可能會直接拿其他網站的性能指標來用，由於每個網站的需求不同、架構不同、用戶的屬性不同、可能連同時上線人數的需求都不太一樣，直接用其他網站的性能目標會讓網站開發團隊十分受傷，因為很有可能這網站永遠達不到性能目標。
所以，網站壓力測試測的是：
- 網站耐壓程度
- 在一定時間內不斷加壓，同時收錄/分析壓測過程中所有設備的效能數據，當任何一個設備發生效能瓶頸時，就是這個網站的效能極限（效能臨界值），並不是網站或資料庫主機掛了才叫「最大極限」。
- 網站穩定度
- 在效能臨界值的壓力下，施以一定時間的壓力測試，例如：10 分鐘、1 小時、2 小時等。
- 在一定時間內如果網站主機還能夠穩定的提供服務，才能代表這個網站經的起長時間的效能考驗。
- 在網站穩定度不佳的情況下，有時候我們會看到網站程式有記憶體洩漏(Memory Leaks)的問題，在長時間的壓力測試下由於記憶體不會被釋放，所以也會導致網站掛掉，這時就可以針對這些不容易發現的問題進行處理。
- 網站性能指標
- 有時候我們會定義網站壓力測試的性能指標是每個頁面的回應時間在特定大量下必須在幾秒內回應，這些是性能指標，必須透過量化數據來改善問題，千萬不要用感覺來分析問題。
- 這項指標最常見的謬誤就是，網頁呈現的速度慢，但伺服器與資料庫的負載都很輕，怎樣調整效能都無法改善，所以就算壓力測試報表數據很漂亮，但客戶還是不能接受的情況。事實上，壓力測試工具都無法幫你測試出網站實際在瀏覽器呈現網頁的效能，這部份屬於「前端程式開發與調校」，必須由網站前端工程師進一步做調校才能改善。
最後，我們就以不動產交易實價查詢服務網為例，搭配 Visual Studio 2012 Ultimate 的 Web 效能和負載測試專案 工具來進行網站壓力測試，各位可以看看如何落實這網站的壓力測試：
※由於我們不是該網站的建置廠商，只能先以「模擬數據」進行分析，文末也不會真的對該網站做壓測，純粹做示範性的案例分析。
環境分析
- 測試設備
- 設備 1 ：受測系統主機 Web1 (採用 NLB 架構)
- 設備 2 ：受測系統主機 Web2 (採用 NLB 架構)
- 設備 3 ：受測系統資料庫主機 DB1
- 設備 4 ：測試控制器主機 VSController1
- 設備 5 ：測試代理程式主機 VSAgent1
- 設備 6 ：測試代理程式主機 VSAgent2
- 設備 7 ：網管型網路交換器 1 台
- 設備 8 ：硬體式防火牆 1 台 ( 可承受 200,000 Sessions )
- 網路環境
- 受測系統：
- Web1: 172.16.44.1
- Web2: 172.16.44.2
- DB 1: 172.16.44.9
- 壓測設備：
- VSController1: 172.16.44.10
- VSAgent1: 172.16.44.101 ~ 172.16.44.150
- VSAgent2: 172.16.44.151 ~ 172.16.44.200
- 系統設定
- 確保所有測試設備間的網路連線是否設定正確，還有 Visual Studio 2012 Ultimate 所需的RemoteRegistry 服務是否開啟，如果沒開啟將無法收錄各電腦之間的效能計數器資料。
- 網站部署
性能指標
由於這是一個全新的網站，無法收集真實的性能指標，但因為不動產實價登錄這議題還算夯，所以無論如何在壓力測試之前還是可以先壓一個概略性的性能指標，以下是預定的壓測目標：
- 可同時間承受 500 人連線
- 在高壓之下所有靜態頁面的頁面回應時間需在 3 秒以內完成
- 針對幾個重要的資料庫查詢表單，執行查詢時需在 10 秒內完成查詢並顯示結果
- 針對表單的思考時間（即使用者輸入資料的時間）約 15 秒鐘
錄製測試情境腳本
依據網站操作動線 (需規劃) 進行測試情境錄製，一個網站應該不只一個操作情境，而是依據不同的網站入口點與不同的操作模式進行規劃，然後設計出多種不同的測試情境。假設我錄製首頁進入後進到「不動產買賣」單元並進行一次搜尋的操作情境，錄製完成後如下圖示：
使用 Visual Studio 2012 Ultimate 錄製時也會紀錄每一次操作的考慮時間 (Think Time)，你可以在錄製完成後從屬性窗格看到「考慮時間」的屬性設定。
設計負載測試範本
測試情境錄製完成後要設計出如何對受測系統施加壓力，所以我們要新增一個「負載測試」項目：
壓測時應加入使用者的「考慮時間」
設定負載模式時，建議使用「逐步執行負載」，這樣比較能模擬出較為真實的使用者人數變化：
給予壓力時有很多種混合測試的方法，組合可以非常多變，這裡我們可以選擇「按虛擬使用者人數」進行測試
如果你有設定多個測試情境的話，可以全部加進來，並依照自訂的比例進行分佈，例如「首頁-不動產買賣」為熱門功能，在所有測試中可以設定為 46%，而其他的測試情境也可以調整，如下圖示：
你還可以依據不同的上網速度來設定，這樣更能模擬出使用者依據不同頻寬測試出不同的模擬情境。但這裡不一定要這麼做，壓力測試不可能執行一次就知道結果，一定會有多種不同的情境進行交叉分析才能得知網站在特定負載下是否能正常運作。
當我們要測試穩定性時，建議設定負載測試持續時間，並指定適當的「準備持續時間」，因為網站剛開站必須先暖一暖身，先模擬 10 個人上來網站，將網站的部分功能執行過一次，爾後再開始執行壓測，這樣數據比較貼近真實的狀況。
完成後畫面如下：
執行壓力測試
這部份可參考胡百敬老師錄製的教學影片：VSTS2010效能及壓力測試 效能測試及壓力測試.zip
壓測報表分析
分析壓測報表也是一門學問，因為不同的欄位代表著不同的意思，還有些專有名稱必須事先理解後才知道到底報表在寫些什麼，重點在哪裡等等。在 Visual Studio 2012 Ultimate 測試控制器上，除了最後的結果報表外，壓測過程中還有許多非常具有價值的效能指標數據，這些都是從每一台電腦的「效能計數器」收錄進來的資料，分析這些數據對報表的真實度影響甚巨，不得不注意。
例如，當你在施加壓力的過程中，如果測試代理主機(VSAgent1)的 CPU 使用率已經高達 100% 的話，那麼也代表著測試代理主機(VSAgent1)已達效能瓶頸，無法再施加相對應的壓力到受測系統上，因此最後產生出來的報表數據也會失真，這點也是另一個常見的操作錯誤，並非所有主機都能模擬出 1,000 位虛擬使用者。
在此我列出 Visual Studio 2012 Ultimate 裡對於測試的層級與相對應的意義，不同層級的報表數據代表的意思有些微不同，因此必須釐清它們之間的階層關係：
- 第一層：測試回合 (代表完成一次負載測試結果，通常一次壓測案例或測試好多次)
- 第二層：情節 (一份測試回合包含多個情節定義)
- 第三層：測試 (一個情節通常混和著多個不同的測試案例)
- 第四層：頁面 (一個測試案例包含多個透過 HTTP 要求)
透過這些大量的數據，相信一定可以從報表中看出許多現有網站的各種問題，但這些分析的經驗很難在一篇文章中寫出，只能有空再寫了。
上線後追蹤與分析
沒有人會保證說經過壓力測試過的程式一定沒有問題，因此網站團隊應該持續追蹤網站上線後的流量變化與網站設備的負載狀況進行分析，如果網站無法負荷未預期的流量則需要進一步擴充硬體或調整程式。
剛看到一則〔實價登錄網今早重新上線 頻寬擴充4倍〕新聞提到該網站頻寬已拓寬至100Mb/s，同時間可容納2,000人次查詢，一天的查詢量可達12萬人次。我也順便對這個說法進行技術分析：
- 網站頻寬已拓寬至100Mb/s
- 應該先從機房的流量圖分析起，看是不是真的機房頻寬不足，如果是的話，提高網站頻寬才有意義，否則只是數字好看＋亂花錢而已。
- 同時間可容納2,000人次查詢
- 這部份只要執行一次網站壓力測試就會得到最準確的數據，說不定測試過程中還會浮現更多沒有發現的問題，不然真的就只是個「說法」而已，建議可以在機房裡再做一次壓測，得到最正確的數字，以供後續參考。（我個人不相信這個數字是真的，因為下午每過幾分鐘網站就會掛掉一次，但線上人數才幾十人而已）
- 一天的查詢量可達12萬人次
- 這個數據基本上沒什麼意義，因為不會有很多人在深夜上這個網站查詢，一個網站的效能瓶頸都是出現在尖峰時刻，只要尖峰時刻可以負荷大量的查詢就夠了，其他時間基本上應該都能夠承受，至於一天的查詢量說 100 萬次應該也說的過去，這樣數字還比較好看。
總結
關於網站壓力測試這邊我整理幾條最基本的測試原則，供各位參考：
- 在測試網站壓力前，請先把網站的 Bugs 給清除乾淨，功能要先做確實，否則測試一個功能有問題的網站系統，以及不斷修修改改的網站，似乎沒什麼意義。再者，壓測過程中通常也會不斷修改網站程式進行效能優化，所以連著 Bugs 一起改程式，恐怕網站品質不會太高。
( 據說不動產交易實價查詢服務網進入查詢頁面前的驗證碼隨便打都會過，呵呵 )
- 徹底降低網路延遲的影響，才能測試出網站真實可承受之壓力。如果客戶的主機無法移動，那就把測試設備都搬進機房測試吧！
- 選對壓測工具，並徹底瞭解工具的使用與報表的數據。
- 壓測過程中要不斷收錄壓測過程中各個環節的數據，有量化的數據才能當成進行科學的分析，而不只是「感覺變快」而已，因為同時 100,000 人、同時 10,000 人在用與同時 10 個人在瀏覽網站時的差別非常大，這些不是用「感覺」可以衡量的。
- 結合多方專業與人才進行壓力測試，彼此貢獻專業技術與知識，不僅測出網站系統的瓶頸，還要能真正調出效能才是王道。
- 從未做過壓力測試的網站，先不急著做壓力測試，而是先分析出目前網站的效能瓶頸，得到基礎的效能數據後，再依據實際需求訂定壓測標準，否則盲目的設定標準只會讓報告不夠精準而已。
- 壓測完成後，應該持續追蹤網站上線後的流量變化，以進一步得到主機實際的負載狀況，如果到達需要擴充設備或調整程式效能時，也比較有個參考依據。
相關連結