新的測試報告，做性能前，最需要確認好測試環境，有的時候客戶經理不太明白，性能測試是怎么回事，問測試要公網的測試報告，尤其是后台的性能測試，我們只能保證其內容效率，公網測試性能相當不嚴謹，難道移動聯通哪天斷網了也是我們得事情嘍？，所以我認為所有的性能均應該在內網環境下進行，性能而是一個是驗證其服務器峰值，一個是驗證其服務器最優值的穩定情況。
報告如下：
此次測試的為坐標偏轉接口，驗證了其峰值查看現存服務器的支撐情況，對運維提出相對意見
坐標偏轉性能
測試報告
| 生效日期 |
2016-1-20 |
版 本 號 |
V1.1 |
|
| 版本狀態 |
□草案 □定稿 ■發布版 □修訂稿 |
|||
| 編 制 人 |
|
編制日期 |
2016-1-20 |
|
| 審 核 人 |
審核日期 |
|||
| 批 准 人 |
批准日期 |
|||
文檔履歷
| 版本 |
修訂日期 |
修訂章節 |
主要修正 |
修訂人 |
審核人/ 批准人 |
| V1.0 |
2015-10-09 |
全部 |
創建坐標偏轉服務性能測試報告v1.0 |
|
|
| V1.0 |
2016-1-20 |
全部 |
創建坐標偏轉服務性能測試報告v1.1 |
|
|
|
|
|
|
|
|
|
1.概述
1.1目的
對阿里雲服務器-坐標偏轉服務進行性能測試，評估坐標偏轉服務的性能狀況。
1.開發正確、有效的性能測試腳本，測試坐標偏轉接口，模擬大量請求，作為此次測試有效實施的基礎；
2.通過性能測試，評估當前雲服務器在生產環境下TPS最大峰值，評估最優值，評估平均請求時間；
3.驗證被測系統的事務處理能力是否滿足在高峰時期的性能要求，為被測系統提供參考依據。為性能瓶頸進行分析提供參考依據。
2.測試環境
2.1壓測模型
測試過程中對應用服務器進行監控，觀察壓力情況下對響應時間的影響。
2.2測試環境
| 主機/ip環境 |
硬件配置 |
操作系統參數 |
測試環境 |
| 坐標偏轉應用服務器 140.205.177.87 （VIP）
|
Inter Xeon E5-2430 CPU 2.20GHz（4核）*2(台) |
Enterprise Linux Server release |
ECS內網 |
| 施壓機 100.69.209.55 |
8核一台 內存:16G 硬盤:總大小500(GB) |
Windows 7 |
ECS內網 |
3.測試方法
壓測測試采用loadrunner性能測試工具，通過創建壓力測試程序，對被測服務器與接口進行自動化壓力測試，最后形成壓力分析報告
3.1壓測模型定義：
本次壓力測試主要選擇針對偏轉服務接口，沒有涉及到其他在線服務調用，擬定壓測接口為ws/mapapi/coordinate/convert。
3.2需求分析
用戶場景設計方案
- 壓測接口的選擇，接近用戶平時使用原則，選擇了單坐標轉換接口作測試。
- 測試峰值使用VUser並發階段500/450/350/300/200來推算兩台雲服務器支持的峰值，優值，隨着測試時間不同評估考量服務器的性能概況，不同階段測試內容和分析。
- 並發數的估算，峰值估算根據500開始進行壓力測試，持續1小時，監測服務器QPS,RT,CPU,MEN等參數狀態，評估服務器負載能力
- 並發持續時間，正常值和優值是根據服務器負載能力控制在30分鍾
- 此次性能測試方案是根據坐標偏轉服務接口從而評定
方案一，峰值測試：持續並發測試1小時，500/450/個VUser時間持續 60分鍾，其中測試過程前后以梯形形式遞增/減少100USR並發，觀察每個階段參數請求，找到系統最大負載能力，如下圖所示：
方案二，壓力測試：持續並發測試，350/300個VUser時間持續 30分鍾，測試直接進行壓力，模擬高峰時段測試，觀察系統穩定性，如下圖所示：
方案三，低峰測試：假設高峰時段VUser為300，為80%用戶請求時段，普通時段為20%用戶，既VUser：88，直接進行壓測，如圖所示：
3.3測試模型建立
由於涉及用戶場景，只考慮客戶調用，分析了內網和測試公網的延遲，不考慮穩定性，值考慮並進行評估，如圖所示：
內網對應用服務器的延遲：7MS
測試外網對應用服務器的延遲：32MS左右
4.測試數據記錄
4.1分析流程：
結果摘要à並發數分析à響應時間àTPS(每秒事務處理量)à業務成功率
4.2數據記錄：
500Vuser：
在2小時內產生共9,398,502點擊量，其中1,335,816失敗http 502均是由服務器down機引起，並且總體平均請求時間246MS,90%在367MS內，已經超出標准，失敗事物達到總事物的七分之一，此並發值已經大大高於服務器的負載能力，且看CPU占用率及LOAD。
平均相應時間：246MS
事物統計：錯誤率14%
CPU，MAX最高99%，其中一台測試過程中down掉了：
Load也已經超出負載
450Vuser：
450Vuesr同500Vuesr，減少了50Vuesr，但同樣在測試過程中跑down了服務器，故需要減持100Vuser用戶查看峰值和服務器負載能力
350Vuesr：
當Vuesr減少到350時，30分鍾內請求了4,577,445點擊量，服務器運行穩定，且接口平均相應時間再也32MS/29MS，90%請求時間在41MS/37MS，事物錯誤率忽略不計。
350Vuesr平均請求時間：32MS
300Vuesr平均請求時間29MS，
事物錯誤率：0.003‰
TPS(每秒事務處理量):2428
CPU：69%，沒有超過70%占用率，正處於負載
LOAD：load在350並發用戶時，屬於最滿負載狀態，任務與請求達到了約1:1
MEN：6%，內存不存在負載情況
80VUser:
模擬其余20%用戶時間，88Vuser並發的請求時間在21MS，90%在24MS，完全滿足＜200MS網絡要求
5.測試結論
5.1測試總結
| Vuesr |
TPS |
響應時間（MS） |
CPU |
LOAD |
錯誤率 |
備注 |
| 500 |
1224 |
246 |
99% |
4.5 |
14% |
Down |
| 450 |
1450 |
35MS |
99% |
4.4 |
40% |
大量失敗，服務器DOWN |
| 350/300 |
2428 |
44 |
60% |
3.6 |
0.003‰ |
|
| 88 |
703 |
21 |
24% |
1.4 |
0% |
|
1.經過多輪測試發現，每秒2500左右的事物處理量（TPS）是該服務測試服務器處理的峰值
2.接口調用偏轉服務，當達到500/450Vuesr時，出現異常較多，約占總數的14-40%，TPS也沒有增加。(HTTP 500失敗以及所抓到的異常是data source request failure底層服務出現異常)，當前服務器此階段測試處理能力較差，但底層服務對負載500-400並發時已經較為吃力。
3.再次經過多倫測試，此接口在300-350並發時錯誤大幅度減少，但350並發用戶是TPS已經開始降低，所以在350並發用戶可以滿足測試標准的小於200MS，且TPS在2500左右。
4.由於是對無流量生產網測試，所以只對用戶場景進行模擬，根據二八定律：80%的請求來自高峰時段。20%請求來自普通時代，所以模擬了高峰時段300並發的TPS在2500上下，30分鍾產生400萬請求量，模擬高峰期1小時，大約產生800W請求量，客戶可評測800W請求量是否對應業務場景。
5.此次測試只評估內網基准，測試該服務程序性能，不確保公網性能。
6. 如果需要達到500Vuser，建議優化資源，服務器的核數都是4核，16G內存，對於CPU達到99%的情況，CPU是瓶頸，內存並沒有占用太多，所以對於應用來說比較浪費，建議將機子升級為為8核CPU，或擴展機器資源，最好有備份，防止業務場景訪問量過大情況。
7.由於不清楚服務器軟件基礎，且沒有對數據庫作測試，請相關技術人員評估測試結果對服務器產生的影響，參考測試過程結果產生的有效參數對服務器進行優化。