1 專案介紹... 3
1.1 測試目的... 3
1.2 縮略語和術語說明... 3
1.3 測試環境配置... 3
2 效能測試工具... 4
3 效能測試方案... 4
3.1 系統壓力測試... 4
3.1.1 系統壓力測試操作步驟... 4
3.1.2 測試通過標準... 4
4 效能測試資料分析... 5
4.1 系統壓力測試報告... 5
4.1.1 系統壓力測試併發數配置... 5
4.1.2 tps. 5
4.1.3 聚合報告... 6
4.1.4 事務響應時間... 6
4.1.5 伺服器監控資料... 6
5 測試結論... 7
專案介紹
測試目的
保證***服務能滿足生產的業務壓力需要。
ss -lnt|grep 9587
listen 0 1024 *:9587 *:*
伺服器相關配置
linux核心版本
uname -a
linux **** 3.10.0-693.5.2.el7.x86_64 #1 smp fri oct 20 20:32:50 utc 2017 x86_64 x86_64 x86_64 gnu/linux
邏輯cpu核數
cat /proc/cpuinfo| grep "processor"| wc -l
8記憶體資訊
cat /proc/meminfo
memtotal: 32781240 kb
效能測試工具
jmeter、nmon等
效能測試方案
系統壓力測試
系統壓力測試是逐步增加系統負載，測試系統效能的變化，並最終確定系統可以最大可承受多大的負載。
系統壓力測試操作步驟
編寫效能測試指令碼
利用測試指令碼，併發測試
測試執行：採用階梯方式，逐步增加併發使用者數，直至在某乙個併發使用者數增加後tps達到峰值。即找到拐點，獲取拐點的負載資料，就是系統可承受的最大負載。
監控伺服器資料
測試通過標準
系統資源消耗
伺服器cpu佔用率<70%
事務通過率》99.9%
最大負載
最大tps可滿足生產環境的需求
效能測試資料分析
系統壓力測試報告
系統壓力測試併發數配置
圖一從100個併發數往上增加，每60秒後增加100個併發數，直到增加到4000個併發數為止停止測試。呈乙個梯度增加併發數（執行緒數）的趨勢。
圖二通過圖二可以看到tps隨著併發數的增加，呈現下降的趨勢。紅色線為通過事務數，綠色線為失敗事務數。在13分左右，也就是併發數在1400時出現失敗的事務，此時通過事務數的比例在99.9%以上，而到達23分左右，即2400個併發數時，通過事務數的比例小於99.9%，滿足測試准出標準，故停止測試。
聚合報告
圖三通過圖三的聚合報告，可以看到從併發數由100開始往上新增直到結束測試的過程中，平均響應時間為1515ms（1.5秒）。
事務響應時間
圖四可以看到圖四事務響應時間隨著併發數的增加，響應時間逐漸增長。雖然出現小幅波動，但在2400個併發數之前，事務響應時間未超過3000ms(3秒)。
伺服器監控資料
平均佔用率
最高佔用率
閒時佔用率
cpu
32.85%
43.10%
12.60%
記憶體
99.30%
99.34%
99.29%
表一
由表一可看出經過sql優化，新增索引之後，對伺服器的壓力減小，cpu不會跑滿。
圖五圖五為執行過程中監控伺服器資料的截圖。linux的負載均值小於cpu核數（8核）。
測試結論
經過效能測試資料分析，可以看到，對伺服器的壓力在可接受範圍內，根據測試准出原則事務通過率需在99.9%以上，故拐點的併發數為2400。建議基於報告中所示的伺服器配置情況下，建議不要超過2400個併發數。
效能測試報告
於感謝分享！1 計畫概述 目的 找出系統潛在的效能缺陷 目標 從安全 可靠 穩定的角度出發，找出效能缺陷，並且找出最佳承受併發使用者數，以及併發使用者數下時間執行的負載情況，如要併發100個使用者，如何對系統分析和調優 3 術語解釋 名詞解釋 4 系統簡介 對乙個什麼系統的測試 5 測試環境 測試範...
MQTT SERVER 效能測試報告
硬體環境 記憶體4g cpu4核 server及埠 apollo埠 61619 mosquitto 埠 1884 activemq埠 1883 emqtt 埠1885 測試方法 併發測試 192.168.6.156 上用 emqttd benchmark 測試 192.168.6.157 上的各mq...
spider RPC效能測試報告
類 別說明 請求報文 響應報文 178位元組 客戶端用例 platformreq req new platformreq createdemo req.setcompanyid 12 req.setsystemid pl 之所以每次http請求呼叫5次spider請求，是因為一開始用單次跑，客戶端很...