本次總結總共分為以下部分：1.如何衡量乙個系統是否要做壓測 2.壓測的準備過程 3.壓測工具選擇 4.壓測資料以及報告結果相關
1.如何衡量乙個系統是否要做壓測
首先需要衡量乙個系統是否需要壓測，從以下角度考慮：
從兩個角度進行分析：
a.業務角度
明確系統是對內使用還是對外使用，使用人數是多少，如果使用人數較少，則併發性的效能測試是沒有必要的
特例，在功能測試時發現明顯的效能問題，則需要進行效能測試排查問題
b.系統角度
1)系統架構
如果乙個系統的框架是老的系統框架，那麼這個系統框架一定是經過驗證的，而如果是新的系統框架，則需要考慮是否做效能測試
2)資料庫要求
效能測試很多時候都是大資料量去訪問/修改資料庫，而瓶頸在於資料庫連線池的數量，而不是資料庫本身的負載或者吞吐量，此時可以結合dba的建議來判斷是否需要進行效能測試
3)系統特殊要求
從實時性角度考慮，某些系統對響應時間要求比較高，比如**系統，系統的快慢直接影響客戶的收益，此時很有必要去做併發量的測試
2.壓測的準備過程
在明確需要進行效能測試後，有以下事項需要確認：壓測目標/目的，以及效能准入準備工作
a.明確壓測目標，壓測目的
明確是為什麼進行壓測，僅僅是為了確定系統的效能還是為了對比加了不同的指令碼後，效能的變化等目的需要明確。就本次而言，是為了明確，新增新的元件對伺服器的影響
壓測目標值確定：在已知線上平時流量高峰qps時，壓測的目標一般為平時流量高峰的3~5倍
壓測過程：
壓測過程中，逐漸加壓，通常情況下，一台髮壓機能承受的執行緒數為1000需要填寫，當cpu使用率為65%左右時，為系統拐點區，超過這個點，系統處理能力將變弱。
得到系統的處理能力拐點時，使用同樣的資料，再加上元件進行壓測，檢視各項指標
3.壓測工具選擇
壓測平台：本次壓測主要為壓測前端介面部分，而公司內部的壓測平台主要是壓測後端介面，以及jmeter也主要是壓測後端介面，
壓測時，主要使用命令：wrk -t -c -d 請求 //壓測單個介面的情況下
多個介面一起併發時，可通過寫shell指令碼後，執行shell指令碼的方式進行壓測
shell指令碼寫法：
建乙個.sh字尾的檔案，把wrk命令放在檔案裡，每行命令後邊寫上空格和&
在壓測機器下，我們可能沒有許可權去直接在bin目錄下建shell指令碼，因此需要切換到home目錄下建立shell指令碼下，shell指令碼路徑：measure01 ~目錄下，test.s**件
接下來，執行這個shell指令碼就可以實現多個介面併發壓測了，執行命令：./sh test.sh
4.壓測資料以及報告結果相關
指標檢視部分：
1.wrk工具進行壓測後，吞吐量的檢視
2.監控看圖進行檢視
效能測試檢視指標
cpu部分：cpu.util 63%左右
qps：吞吐量比較（什麼樣的情況吞吐量是合理的，如果對比是否加了lua指令碼的情況下，對比同樣的請求下，吞吐量的變化）
記憶體占用
磁碟占用
前端效能測試分析
web瀏覽器與web伺服器之間通過http協議進行通訊的過程。所以，web c s之間握手的協議就是http協議。遞迴尋找dns server 連線目標ip並建立tcp連線 向目標伺服器傳送http請求 web伺服器接收請求後處理 web伺服器返回相應的結果 無效 重定向 正確頁面等 瀏覽器接收返回...
效能測試 效能測試步驟
針對此次庫內作業效能測試，梳理一下期間的工作流程 梳理已有的介面指令碼，確認需要做效能測試的幾個介面，即使用率高，對效能有要求的幾個主要介面。結合頁面的操作，和確認的介面，梳理具體的業務邏輯 同時，請開發人員部署了測試環境。測試環境的伺服器指標，盡量和生產環境一致。部署的時候，負載均衡等情況也盡量和...
效能測試 效能測試全流程之前期準備工作
一，測試準備階段 1.1，效能任務分析 測試範圍確定 一般測試系統對效能測試範圍的選擇，遵循如下幾個原則 1 系統選取佔總交易量80 的交易，做為基礎業務模型 2 據業務量大小選取典型交易，一般通過統計生產系統交易量排序top10 top20確定 3 選取生產系統中消耗資源最多，或者耗時最長的業務交...