京東全球年中購物節火熱進行中，2018年6月1日0點到6月18日24點累計下單金額達1592億元，出庫訂單金額同比增長超過37%！618期間，90%

以上自營訂單實現當日達或次日達。在這要為物流研發系統高性能、高穩定點贊！這離不開備戰階段必做的一件事：對系統持續壓測和優化。你的系統做了嗎？

性能測試的正確打開方式，現在開始

不可不知的性能測試二三事

1.1 性能測試是什麼？

通過模擬真實用戶行為設計不同場景組合，並參考歷年線上數據量，測試系統是否滿足性能要求和發現系統問題並進行調優。

1.2 常見性能指標

吞吐量：單位時間內服務器處理客戶請求的數量，常用TPS表示，即Transactions Per Second。

響應時間：端到端時間，即客戶端發出請求開始，到客戶端收到所有數據所消耗的時間，通常關注業務的平均響應時間和TP99，TP99表示99%的請求在此時間內。

併發用戶數：同一時刻與服務器進行數據交互的所有用戶數量。

1.3 TPS與響應時間的誤會？

如接口一次調用響應時間100ms，那麼每秒鐘可調用10次，由此可知接口的TPS=10次/秒?

多次聽到這樣的推斷過程，我們再仔細思考下：應用通常是多線程併發處理，線程之間也存在資源爭用等問題。響應時間和TPS存在相關性，但不是簡單的線性關係。

1.4 性能指標之間關係？

上圖是典型的併發用戶數、TPS（吞吐量）、響應時間和系統資源關係模型：

（1）系統無瓶頸時：併發用戶數↑，TPS↑，系統資源↑，業務響應時間無明顯增長；

（2）系統達到瓶頸時：併發用戶數↑，TPS↓，系統資源維持較高水平，業務響應時間明顯↑。

1.5 性能測試時機

性能測試的時機很重要！一般而言，只有在系統基礎功能測試完成、系統趨於穩定的情況下，才會進行性能測試，否則性能測試是無意義的。

新手性能測試如何開展？

這裡重點說明性能測試最核心的流程，幫助大家快速上手項目，其他流程也很重要，請大家持續探索。

2.1 需求調研

需求是性能測試的起始點，明確測試目的和指標,指引性能測試正確實施。

2.1.1 需求分析

（1）根據項目背景，從性能領域分析測試目的：

（2）用戶場景剖析和業務建模：根據對系統業務、用戶活躍時間、訪問頻率、場景交互等各方面的分析，獲得系統的典型業務高峰期調用情況，例如：選擇高峰期調用量Top10業務，作為本次壓測的內容。

2.1.2 量化性能目標

根據本次性能測試的應用領域結合系統的業務特點，由業務模型推到測試模型，量化性能測試指標，如：

（1）10分鐘接單60萬，即TPS=60萬/10分鐘=1000單/秒；

（2）接單接口響應時間不超過50ms；

（3）應用服務器CPU<60%，數據庫磁盤disk busy<40%等。

2.1.3 測試方案

主要明確測試目的、測試計劃、測試環境、測試用例、性能指標等。

2.2 測試準備

2.2.1 測試環境

測試環境包括：硬件環境、操作系統、應用服務等組成。搭建測試環境原則：與生產環境軟硬件、服務版本、參數配置保持對應。同時保持測試環境的乾淨和穩定，不受外來因素影響。

例如線上評估型壓測：可在預發佈環境測試，準備一個壓測分組。

2.2.2 壓測工具及測試腳本

針對京東業務常見的JSF接口，我們研發了一套極簡壓測工具，實現：場景設計、生成腳本、發送壓力、性能監控及結果收集。

提供一下接口基本信息就可輕鬆做壓測。

壓測工具同樣支持HTTP協議快速壓測。

2.3 測試執行

2.3.1 測試執行

初次性能測試會遇到疑問？併發用戶數設置多少合適？應該執行多長時間？

執行步驟介紹：

1.驗證測試：

驗證被測業務調用成功，腳本開發正確；

併發用戶數=1 執行次數=1；

接口返回值正確，斷言成功。

2.基準測試：

併發用戶數=1，執行次數=100 或 執行時間=10分鐘

3.負載測試：

用戶數的設置：按固定步長增加併發用戶數，直到系統達到瓶頸；

併發用戶數步長可根據系統業務和經驗確定，如：

情況一：用戶數=10，CPU=20%，此時每輪壓測可以10個用戶遞增，1 10 20 …

情況二：用戶數=10，CPU=5%,此時每輪壓測可以考慮以30個用戶遞增，1 30 60…

根據測試結果分析，適當增加、刪除壓測輪次。

執行時間=10分鐘

4.穩定性測試：

給系統加載一定壓力，使系統運行一段時間，檢查系統的穩定性，一般測試時間N*12小時，系統壓力一般設置為最大吞吐量的80%。

以上為測試執行基本步驟，根據測試目的的不同，適當增減。

2.3.2 性能監控

性能監控通用的監控有業務性能指標（TPS、TP99、Users）、服務器硬件性能指標（CPU、MEM等），其他監控與系統架構相關，例如：JVM、DB、JimDB等。

京東有非常完善的監控平臺：UMP平臺、MDC平臺、JimDB監控平臺等，Qone壓測工具可以將業務性能指標、服務器資源監控彙總到一起，一站式觀察性能過程指標。

2.3.3 執行結果

執行完測試後，對結果進行整理分析，是否滿足需求調研時明確的指標。

上圖是某接口的性能結果，併發用戶=25，此業務達到最佳TPS=13957，TP99=10ms，CPU=88%，判斷此時是否達到預期目標。(併發用戶數=30時，TP99從10ms到20ms增大200%，TPS從13957到14530,只增長4%，系統明顯存在瓶頸)。

2.3.4 性能調優

下面是一個典型的系統架構圖：

影響性能的因素很多，硬件設備、網絡、數據庫、應用程序等，根據經驗或由外及裡（硬件資源、網絡到程序代碼級別）順序排查系統瓶頸產生的原因，有針對性的進行優化。

2.4 測試報告

測試結果是否滿足測試目標，測試過程數據，調優過程及前後性能對比。

某系統性能測試報告示例：

XX系統性能測試報告

性能測試結論

線上壓測集群，數據庫一主五從結構，混合業務場景總TPS=459次/秒，滿足預期指標333次/秒。

此時web服務器CPU= 52%，數據庫主庫CPU=8%，disk busy=11%，數據庫從庫CPU=4%，disk busy=2%。

穩定性測試：應用服務器 CPU=30%時，持續壓測12小時，系統未出現異常。

測試詳細數據

調優事項

風險與問題

測試環境

應用服務器：壓測集群

數據庫：一主五從

乾貨小結

分享一些性能測試的感悟，希望對大家有所幫助：

（1）任何脫離需求的性能測試都是耍流氓；

（2）性能調優不一定要一步到位，從40s到10s就是一次性能調優；

（3）平衡性能優化和調優成本；

（4）接受合理誤差可以省去很多麻煩；

（5）性能測試離不開技術、管理、溝通。