以下是小弟寫的報告樣本，性能剛學，懂得不太多，希望拍磚指正。
API雲服務器性能
測試報告
| 生效日期 |
2015-06-12 |
版 本 號 |
V1．0 |
|
| 版本狀態 |
□草案 □定稿 ■發布版 □修訂稿 |
|||
| 編 制 人 |
段旭 |
編制日期 |
2015-6-12 |
|
| 審 核 人 |
審核日期 |
|||
| 批 准 人 |
批准日期 |
|||
文檔履歷
| 版本 |
修訂日期 |
修訂章節 |
主要修正 |
修訂人 |
審核人/ 批准人 |
| V1.0 |
2015-06-12 |
全部 |
創建API雲服務器性能測試報告 |
段旭 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.概述
1.1目的
對阿里雲遷移-API搜索服務進行性能測試，客觀，公正評估API在雲服務器上表現得性能狀況。
1.開發正確、有效的性能測試腳本，測試新聞類接口，模擬客戶方請求，作為此次測試有效實施的基礎；
2．通過性能測試，評估當前雲服務器測試環境下被測系統的各項性能表現；
3．驗證被測系統的事務處理能力是否滿足在高峰時期的性能要求，為被測系統提供參考依據。為性能瓶頸進行分析提供參考依據
1.2適用范圍
適用於XXXX內部，運維組，項目組，開發組，測試組等
1.3測試階段
| 測試時間 |
測試階段 |
並發數 |
測試環境 |
測試內容 |
測試分析 |
| 2015年6月8日20:00-00:00 |
首輪測試 |
1000 |
公司公網Wifi |
實驗性測試，查看服務器質量，測試本機承載能力，遇到大量連接超時錯誤， |
分析是由三點引起 1.服務器負載均衡引起2.服務器性能引起 3.本地測試機引起 |
| 2015年6月9日12:00-13:21 |
第二次測試 |
1000 |
公司公網Wifi |
3台負載機一起並發測試，並重新測試了一下其他知名網站，發錯錯誤依據出現大量錯誤，但相對首次較少 |
1.本地測試機無意，需要調整到有線網絡測試網絡 2.服務器性能引起
|
| 2015年6月11 11:25-13:38 |
第三次測試 |
20 |
有線網絡 |
測試20個並發用戶分析，沒有遇到錯誤 |
1.服務器響應很快，但其中一台服務器各項性能負載較大 |
| 2015年6月11 16:52-18:06 |
第四次測試 |
800 |
有線網絡 |
經過多次實驗測試，測試了2台負載機800並用戶，一台分別400並發 |
平均每秒點擊次數控制在461次/秒，吞吐量6698054.678字節/秒 |
| 2015年6月11 18:31-23:01 |
第五次測試 |
1000 |
有線網絡 |
對服務器進行測試，其中一台負載機在測試過程中退出，查看各項測試指數 |
平均每秒點擊次數控制在451次/秒，吞吐量6557583.198字節/秒 |
2．測試方法
壓測測試采用loadrunner性能測試工具，通過創建壓力測試程序，對被測服務器與接口進行自動化壓力測試，最后形成壓力分析報告
2.1壓測模型：
測試過程中對雲OS服務器進行監控，觀察並發用戶時對服務器產生的影響。
2.2壓力測試流程：
2.2.1測試環境：
阿里雲服務器，SLB：http://141.215.174.22（這個只是模擬錯誤的SLB）
負載機，（CPU：core I5，內存8G，硬盤500G 7200轉） *2台
測試軟件：采用Mercury Interactive公司的LoadRunner測試及分析軟件作為測試工具。
2.2.2壓力模型定義：
本次壓力測試主要選擇DB類應用接口，沒有涉及到其他在線服務調用。擬定壓測接口為/audi/ws/news/browse/ url如下：http://141.215.174.22/audi/ws/news/browse/?channel=audi&uuid=22263&output=xml&sign=EFA4C76D7324A52198C6701B165B122C&from=telematics_monitor
2.2.3測試准備與標准
模擬並發1000用戶，接口平均請求時間＜500MS，測試請求時間平均4個小時
2.2.4測試執行：
分階進行壓力測試，分析各階段性能標准，排查相應問題。
2.2.5測試報告輸出
測試結果確認有效后，將壓測結果形成報告形式發出。
3.測試模型建立
由於不涉及用戶場景，只考慮客戶調用
每分鍾啟動100個用戶，當達到1000用戶時所有用戶持續運行3分30
4.性能測試結果分析
4.1分析流程：
結果摘要à並發數分析à響應時間à每秒點擊次數à業務成功率à系統資源
4.1.1
結果摘要：
摘要最后一次1000並發用戶結果顯示
該部分信息包括：測試時間，如下圖所示在4小時29分鍾，與場景計划中時間基本吻合
| 平均事務響應時間（秒） |
最大事務響應時間 |
最小事務響應時間 |
平均每秒點擊次數 |
平均每秒吞吐量（字節/每秒） |
通過事務數 |
失敗事務數 |
| 1.042 |
3.601 |
0.17 |
451.334 |
6557583 |
7303492 |
99 |
我們只是針對靜態接口測試，所以每秒點擊次數很能直觀的看出被測服務器的處理能力，對於吞吐量，單位時間內吞吐量越大，說明服務器的處理能越好，而請求數僅表示客戶端向服務器發出的請求數，與吞吐量一般是成正比關系
4．1.2並發用戶
由於測試場景時，一台負載機掛了，所以導致在測試30分鍾時，變成了500並發用戶請求，不過雖然500並發用戶請求也能分析服務器的性能標准
1000降到500並發圖
800並發設計場景圖
4.1.3平均事務響應時間圖
800平均相應時間圖
1000降到500
看完了“Average Time”，我們再看“90 Percent Time”，這個時間從某種程度來說，更准確衡量了測試過程中各個事務的真實情況，表示90%的事務，服務器的響應都維持在某個值附近，“Average Time”值對於平均事務響應時間變動趨勢很大的情況統計就不准確了，比如有三個時間：1秒、5秒、12秒，則平均時間為6秒，而另外一種情況：5秒、6 秒、7秒，平均時間也為6秒，顯然第二種比第一種要穩定多了。所以，我們在查看平均事務響應時間的時候，先看整體曲線走勢，如果整體趨勢比較平滑，沒有忽 上忽下的波動情況，取“Average Time”與“90 Percent Time”都可以，如果整體趨勢毫無規律，波動非常大，我們就不用“Average Time”而使用“90 Percent Time”可能更真實些。
4.1.4每秒點擊次數
“Hits per Second（每秒點擊數）”反映了客戶端每秒鍾向服務器端提交的請求數量，如果客戶端發出的請求數量越多，與之相對的“Average Throughput (bytes/second)”也應該越大，並且發出的請求越多會對平均事務響應時間造成影響，所以在測試過程中往往將這三者結合起來分析。圖1- 11顯示的是“Hits per Second”與“Average Throughput(bytes/second)”的復合圖，從圖中可以看出，兩種圖形的曲線都正常並且基本一致，說明服務器能及時的接受客戶端的請 求，並能夠返回結果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，則表示服務器雖然能夠接受服務器的請求，但返回結果較慢，可能是程序處理緩慢。如果“Hits per Second”不正常，則說明客戶端存在問題，那種問題一般是網絡引起的，或者錄制的腳本有問題，未能正確的模擬用戶的行為。具體問題具體分析，這里僅給 出一些建議。
1000
800
4.1.5業務成功率
800
1000-500
從圖中可以看出，所有的Aciton都是綠色的，即表示為Passed，同時除了vuser_init與vuser_end兩個事務，其他的事務通過數為 2163，也就表明在30分鍾的時間里，共完成了2163次登錄考勤業務操作。那么根據這些可以判斷本次測試登錄業務與考勤業務的成功率是100%，再次 更新測試結果記錄表如表2所示
4.1.6系統資源
系統資源圖顯示了在場景執行過程中被監控的機器系統資源使用情況，一般情況下監控機器的CPU、內存、網絡、磁盤等各個方面。本次測試監控的是測試服務器的CPU使用率與內存使用率，以及處理器隊列長度
從圖中可以看出，CPU使用率、可用物理內存、CPU的隊列長度三個指標的曲線逗較為平滑，三者的平均值分別為：53.582%、83.456M、 8.45，而測試服務器總的物理內存為384M，那么內存使用率為（384-83.456）/384=78.26%，根據本次性能測試要求的：CPU使用 率不超過75%，物理內存使用率不超過70%這兩點來看，內存的使用率78.26%大於預期的70%，故內存使用率不達標。根據Windwos資源性能指 標的解釋，一般情況下，如果“Processor Queue Length（處理器隊列長度）”一直超過二，則可能表示處理器堵塞，我們這里監控出來的數值是8.45，而且總體上保持平衡，那么由此推斷，測試服務器 的CPU也可能是個瓶頸。同時在測試過程中，場景執行到23分半鍾的時候，報出了錯誤！未找到引用源。的錯誤，意思是說被監控的服務器當前無法再進行計數器數據的獲取了，所以，本次操作系統資源的監控只得到了場景執行的前23分半鍾的數據。這樣對本次測試結果有一定的影響。