網站的性能測試(一)
今天有收到要進行網站性能測試的需求,我的一位主管給了一個參考網址,如下:
http://www.microsoft.com/taiwan/msdn/columns/web_service_app/Web_Service_App_20041224.htm
程式部署與效能調校最佳實務專欄： Web Services 應用程式效能調教 作者：胡士亮 (台灣微軟平台架構技術副理) 2004 年 12 月 回應速度與延展性是在這個 IT 世代是決定應用程式成功或失敗的關鍵。效能不佳的應用程式會造成企業營利上的損失，包括降低員工的生產力、增加開發與硬體成本、損害客戶關係等等嚴重的問題。不管對程式開發者或者系統管理者來說，應用程式效能調教一直是心中永遠的痛。對 Web Service 的開發者來說，這個問題更加嚴重。Web Services，包括 Web 介面的應用程式與在服務導向架構 (SOA) 中扮演重要角色的 Web Service，必須面對 Internet 上突然暴增的要求數量，更凸顯了應用程式效能管理的重要性。但是對開發人員來說，傳統的開發流程從使用者需求開始，到測試與上線為止，幾乎把所有的時間放在如何把使用者的功能需求開發出來、和程式臭蟲 (Bug) 搏鬥以及趕在產品上市前完成這幾件項目上，至於效能部分往往是上線運轉之後才開始面對。如何在設計規劃效能良好的架構、如何開發使用資源少執行速度快的程式碼、如何測試取得應用程式的效能數據、如何部署應用程式避免硬體瓶頸、如何持續偵測管控上線後的效能狀況與問題一直困擾著資訊專業人員。 為了妥善管理 Web Service 應用程式效能，在應用程式開發過程中必須考慮下列事項： 設定效能目標: 在使用者需求分析階段增加效能目標設定資料，並將效能目標加入系統功能需求書中。效能目標應該要包括下列項目： 回應時間 (Response time)：系統執行特定功能所需時間，例如網路下單確認。 處理能力 (Throughput)：每秒支援的工作量。包括每秒要求次數 (Request per second)，每秒交易次數 (Transaction per second) ，每秒網路流量 (Byte per second)。 資源使用量 (Resource Utilization)：系統執行特定功能時使用系統資源的百分比與使用時間。包括處理器、記憶體、硬碟存取、與網路存取等。 工作量 (Workload)：使用者使用系統的習慣，包括最大使用者人數、同時上線人數、資料量、交易量、與交易種類等。 設計階段效能考量 在設計階段將效能需求放入系統分析中。目前許多人常用 UML 來進行系統分析與設計，而在效能考量部分則是使用 Performance Modeling 來協助評估系統架構以符合效能目標。Performance Modeling 可分為以下八個步驟： 確認主要使用情境 (Scenario)：找出最在乎執行效能的使用情境，這些使用情境會對整個應用程式的效能造成威脅。 確認工作量：找出系統需要支援多少使用者與同時存取人數。 確認效能目標：訂定每個主要使用情境的效能目標，效能目標符合企業需求。 確認預算：訂出硬體預算與限制，包括處理器、記憶體、硬碟存取、網路支援的最大運算能力 確認處理流程：將主要使用情境處理與系統元件的互動流程訂定出來, 可以配合使用 UML Use Case Scenario 分配預算：經步驟 4 的預算分配到步驟 5 的處理流程上並滿足效能目標 評估：評估系統設計是否符合目標與預算，您可能需要調整設計或重新分配預算來滿足效能目標 驗證：驗證您的設計符合目標與預測，透過不斷重複的雛型、測試、評量來確認設計是正確的 效能測試 效能測試是評估應用程式能否支援預期與尖峰工作量，以及是否能夠延展來提高容量。效能測試包括下列步驟： 確認主要使用情境：找出需要測試潛在效能問題的使用情境 確認工作量：訂出上項情境中所需支援的使用者與同時存取人數，這可以從需求中找出平時與最大使用者人數。 確認測量數據： 訂出效能測試時所需收集與應用程式相關的測試數據用來找出潛在的效能瓶頸。 建立測試範例 (Test Case)： 建立測試範例，需包含測試所需的步驟與預期結果。 壓力測試：透過工具來執行測試範例的壓力測試，並收及相關測量數據 分析結果：分析壓力測試所收集到的相關測量數據。 效能調教 效能調教流程是不斷重複的找出系統瓶頸並消除直到應用程式達到預計的效能目標為止。整個過程包括建立效能基準 (Baseline)、收集測量數據、分析數據找出效能瓶頸、調整系統設定、再度收集測量數據以確認調整結果 以上就是完整的應用程式效能管理所需的步驟。接下來舉一個 Web Service 應用程式效能調教的實例。 客戶的 Web 應用系統包括前端 Windows 2000 IIS 網站伺服器，應用程式使用 ASP 與 Visual Basic 6.0 開發的 COM+ 元件，後端 SQL 2000 資料庫存放的大量的客戶與商品資料，應用程式透過 ADO 物件存取資料庫。這套應用系統在離峰時間並沒有太大問題，系統回應時間都在可接受範圍內，問題是發生在晚上 6 到 10 點的尖峰時間中，系統常發生回應時間超過 1000 秒、IIS 500 內部錯誤、IIS 500.13 Server too busy 等問題造成使用者抱怨不斷。 在開始執行效能調教步驟，先收集網路、系統、平台、應用程式相關效能數據。在網路、系統與平台這部分使用Windows 2000 內建的效能工具來收集效能資訊，共收集下列效能項目與物件： Active Server Pages\Requests Queued Active Server Pages\Requests/Sec Active Server Pages\Sessions Current Memory\Available Bytes Memory\Pages/sec PhysicalDisk\% Disk Time PhysicalDisk\Current Disk Queue Length Processor\% Processor Time Web Service\Byte Received/sec Web Service\Bytes Sent/sec Web Service\Current Connections Web Service\Maximum Connections 圖 1 Windows 2000 內建效能工具分析收集到的效能資訊發現，Web Server 在晚上 7 點到 11 點的尖峰期間 ASP/Request Queued 值高達 71，並且超過 20 以上的時間持續5分鐘以上，表示 ASP 程式有執行時間過長的問題。資料庫伺服器在尖峰時間 PhysicalDisk\Current Disk Queue 最大值 117，且平均值超過 16，表示硬碟 I/O 速度不夠快；SQL Server\Table Lock Wait Time 最大值 1328 秒而且不只一次，表示 SQL 有 Lock/Block 問題；SQL Server\Full Scan/sec 最大值 1108 平均值 34，表示對資料庫的查詢沒有使用索引，由於效能資料發現 ASP/Request Queued 值很高，表示 ASP 程式有執行過長的問題。為了找出是哪些 ASP 程式有問題，我們可以透過分析 IIS Log 來發現。在使用 IIS Log 來找出執行時間過長的問題時，首先我們必須先增加 IIS Log 的紀錄欄位包含 Time Taken 欄位，這個欄位存放 ASP 程式在伺服器端的執行時間。圖 2 設定 IIS Log增加Time Taken欄位由於 IIS Log 的大小十分龐大，必須使用工具來分析。我選用的工具是 SQL Server DTS + OLAP + Excel 樞紐分析表來進行分析。首先先使用 SQL DTS 將 IIS Log 資料匯入資料庫，接著建立 OLAP Cube，在使用 Excel 樞紐分析表來進行分析的工作，很快就能所訂執行時間過長的 ASP 程式與發生問題時間與錯誤類型圖 3 Excel 樞紐分析表顯示各類型檔案執行筆數與最長最短時間圖 4 ASP 程式執行時間超過 60 秒筆數與執行結果圖 5 ASP 程式執行錯誤數量分布透過找出發生問題的 ASP 程式並分析 ASP 程式執行時間花費過長的部分進行效能調教，可以改善發生問題最嚴重的程式，接著在收集效能資料繼續找出造成效能問題的瓶頸家以改善。根據 80/20 法則，80% 的效能問題是由 20% 的程式造成，找過幾輪後就可以發現 Web 應用程式的效能顯著改善，減少開發與管理者的壓力並且讓使用者能更順利的完成每日工作，提高生產效率。以上是針對 Web Service 應用程式效能調教方法簡介與案例介紹，希望能讓您更了解如何來進行效能調教的工作。參考資料MSDN Patterns & Practices：http://msdn.microsoft.com/practicesVS.Net Design Goals： Performance：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconscalability.aspIIS 6.0 Performance and Scalability：http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx
http://www.microsoft.com/taiwan/msdn/columns/web_service_app/Web_Service_App_20041224.htm
程式部署與效能調校最佳實務專欄： Web Services 應用程式效能調教 作者：胡士亮 (台灣微軟平台架構技術副理) 2004 年 12 月 回應速度與延展性是在這個 IT 世代是決定應用程式成功或失敗的關鍵。效能不佳的應用程式會造成企業營利上的損失，包括降低員工的生產力、增加開發與硬體成本、損害客戶關係等等嚴重的問題。不管對程式開發者或者系統管理者來說，應用程式效能調教一直是心中永遠的痛。對 Web Service 的開發者來說，這個問題更加嚴重。Web Services，包括 Web 介面的應用程式與在服務導向架構 (SOA) 中扮演重要角色的 Web Service，必須面對 Internet 上突然暴增的要求數量，更凸顯了應用程式效能管理的重要性。但是對開發人員來說，傳統的開發流程從使用者需求開始，到測試與上線為止，幾乎把所有的時間放在如何把使用者的功能需求開發出來、和程式臭蟲 (Bug) 搏鬥以及趕在產品上市前完成這幾件項目上，至於效能部分往往是上線運轉之後才開始面對。如何在設計規劃效能良好的架構、如何開發使用資源少執行速度快的程式碼、如何測試取得應用程式的效能數據、如何部署應用程式避免硬體瓶頸、如何持續偵測管控上線後的效能狀況與問題一直困擾著資訊專業人員。 為了妥善管理 Web Service 應用程式效能，在應用程式開發過程中必須考慮下列事項： 設定效能目標: 在使用者需求分析階段增加效能目標設定資料，並將效能目標加入系統功能需求書中。效能目標應該要包括下列項目： 回應時間 (Response time)：系統執行特定功能所需時間，例如網路下單確認。 處理能力 (Throughput)：每秒支援的工作量。包括每秒要求次數 (Request per second)，每秒交易次數 (Transaction per second) ，每秒網路流量 (Byte per second)。 資源使用量 (Resource Utilization)：系統執行特定功能時使用系統資源的百分比與使用時間。包括處理器、記憶體、硬碟存取、與網路存取等。 工作量 (Workload)：使用者使用系統的習慣，包括最大使用者人數、同時上線人數、資料量、交易量、與交易種類等。 設計階段效能考量 在設計階段將效能需求放入系統分析中。目前許多人常用 UML 來進行系統分析與設計，而在效能考量部分則是使用 Performance Modeling 來協助評估系統架構以符合效能目標。Performance Modeling 可分為以下八個步驟： 確認主要使用情境 (Scenario)：找出最在乎執行效能的使用情境，這些使用情境會對整個應用程式的效能造成威脅。 確認工作量：找出系統需要支援多少使用者與同時存取人數。 確認效能目標：訂定每個主要使用情境的效能目標，效能目標符合企業需求。 確認預算：訂出硬體預算與限制，包括處理器、記憶體、硬碟存取、網路支援的最大運算能力 確認處理流程：將主要使用情境處理與系統元件的互動流程訂定出來, 可以配合使用 UML Use Case Scenario 分配預算：經步驟 4 的預算分配到步驟 5 的處理流程上並滿足效能目標 評估：評估系統設計是否符合目標與預算，您可能需要調整設計或重新分配預算來滿足效能目標 驗證：驗證您的設計符合目標與預測，透過不斷重複的雛型、測試、評量來確認設計是正確的 效能測試 效能測試是評估應用程式能否支援預期與尖峰工作量，以及是否能夠延展來提高容量。效能測試包括下列步驟： 確認主要使用情境：找出需要測試潛在效能問題的使用情境 確認工作量：訂出上項情境中所需支援的使用者與同時存取人數，這可以從需求中找出平時與最大使用者人數。 確認測量數據： 訂出效能測試時所需收集與應用程式相關的測試數據用來找出潛在的效能瓶頸。 建立測試範例 (Test Case)： 建立測試範例，需包含測試所需的步驟與預期結果。 壓力測試：透過工具來執行測試範例的壓力測試，並收及相關測量數據 分析結果：分析壓力測試所收集到的相關測量數據。 效能調教 效能調教流程是不斷重複的找出系統瓶頸並消除直到應用程式達到預計的效能目標為止。整個過程包括建立效能基準 (Baseline)、收集測量數據、分析數據找出效能瓶頸、調整系統設定、再度收集測量數據以確認調整結果 以上就是完整的應用程式效能管理所需的步驟。接下來舉一個 Web Service 應用程式效能調教的實例。 客戶的 Web 應用系統包括前端 Windows 2000 IIS 網站伺服器，應用程式使用 ASP 與 Visual Basic 6.0 開發的 COM+ 元件，後端 SQL 2000 資料庫存放的大量的客戶與商品資料，應用程式透過 ADO 物件存取資料庫。這套應用系統在離峰時間並沒有太大問題，系統回應時間都在可接受範圍內，問題是發生在晚上 6 到 10 點的尖峰時間中，系統常發生回應時間超過 1000 秒、IIS 500 內部錯誤、IIS 500.13 Server too busy 等問題造成使用者抱怨不斷。 在開始執行效能調教步驟，先收集網路、系統、平台、應用程式相關效能數據。在網路、系統與平台這部分使用Windows 2000 內建的效能工具來收集效能資訊，共收集下列效能項目與物件： Active Server Pages\Requests Queued Active Server Pages\Requests/Sec Active Server Pages\Sessions Current Memory\Available Bytes Memory\Pages/sec PhysicalDisk\% Disk Time PhysicalDisk\Current Disk Queue Length Processor\% Processor Time Web Service\Byte Received/sec Web Service\Bytes Sent/sec Web Service\Current Connections Web Service\Maximum Connections 圖 1 Windows 2000 內建效能工具分析收集到的效能資訊發現，Web Server 在晚上 7 點到 11 點的尖峰期間 ASP/Request Queued 值高達 71，並且超過 20 以上的時間持續5分鐘以上，表示 ASP 程式有執行時間過長的問題。資料庫伺服器在尖峰時間 PhysicalDisk\Current Disk Queue 最大值 117，且平均值超過 16，表示硬碟 I/O 速度不夠快；SQL Server\Table Lock Wait Time 最大值 1328 秒而且不只一次，表示 SQL 有 Lock/Block 問題；SQL Server\Full Scan/sec 最大值 1108 平均值 34，表示對資料庫的查詢沒有使用索引，由於效能資料發現 ASP/Request Queued 值很高，表示 ASP 程式有執行過長的問題。為了找出是哪些 ASP 程式有問題，我們可以透過分析 IIS Log 來發現。在使用 IIS Log 來找出執行時間過長的問題時，首先我們必須先增加 IIS Log 的紀錄欄位包含 Time Taken 欄位，這個欄位存放 ASP 程式在伺服器端的執行時間。圖 2 設定 IIS Log增加Time Taken欄位由於 IIS Log 的大小十分龐大，必須使用工具來分析。我選用的工具是 SQL Server DTS + OLAP + Excel 樞紐分析表來進行分析。首先先使用 SQL DTS 將 IIS Log 資料匯入資料庫，接著建立 OLAP Cube，在使用 Excel 樞紐分析表來進行分析的工作，很快就能所訂執行時間過長的 ASP 程式與發生問題時間與錯誤類型圖 3 Excel 樞紐分析表顯示各類型檔案執行筆數與最長最短時間圖 4 ASP 程式執行時間超過 60 秒筆數與執行結果圖 5 ASP 程式執行錯誤數量分布透過找出發生問題的 ASP 程式並分析 ASP 程式執行時間花費過長的部分進行效能調教，可以改善發生問題最嚴重的程式，接著在收集效能資料繼續找出造成效能問題的瓶頸家以改善。根據 80/20 法則，80% 的效能問題是由 20% 的程式造成，找過幾輪後就可以發現 Web 應用程式的效能顯著改善，減少開發與管理者的壓力並且讓使用者能更順利的完成每日工作，提高生產效率。以上是針對 Web Service 應用程式效能調教方法簡介與案例介紹，希望能讓您更了解如何來進行效能調教的工作。參考資料MSDN Patterns & Practices：http://msdn.microsoft.com/practicesVS.Net Design Goals： Performance：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconscalability.aspIIS 6.0 Performance and Scalability：http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx
浙公网安备 33010602011771号