壓測目標
- 讀請求接口1.6W併發，總請求16W
- 寫請求接口8K併發，總請求8W
壓測前的準備工作
- 分析所有接口是否存在可能的性能問題
- 靜態代碼分析
- 採用Yii2提供的debug工具進行分析
- 採用xhprof進行性能分析
- 壓測代碼準備
- 生成壓測相關數據
- 編寫壓測代碼(有用戶態的接口需要做模擬用戶登錄)
- 人員準備
- 5位開發人員
- 1位測試人員
- 1位運維人員
- 人員分工
- 運維人員進行服務器部署，配置修改，查詢各種服務器性能監控
- 開發人員進行代碼分析，檢測新部署服務器各種配置項，對單臺服務器性能進行測試，推測大概需要的服務器配置及臺數，對出現的問題進行分析，得出解決方案，進行壓測
- 測試人員全流程測試新部署服務器是否正常，對開發人員給出的接口壓測報告進行加工，生成可視化的壓測報告。包含不侷限於接口地址、強併發數、總請求數量或者持續時間、接口響應報告（eg:90%的請求2s以內返回）、web服務器負載情況、數據庫負載和redis等存儲的負載）。每臺web服務器能支持的最大請求數量、暴露在極限情況下的資源瓶頸（數據庫、web服務器或者其他）。
服務器及客戶端配置要求
- SLB：最大併發數：50000，按量收費，帶寬無上限（上限5Gbps，可調）
- WEB服務器：4C8G，600PHP-FPM，不需要外網，單臺壓測極限能達到800併發，爲了給服務器預留資源，按500併發計算，需要32臺服務器。
- RDS集羣：單臺9C6G，IOPS:3000,最大連接數：1500
- Redis集羣：內存16G，最大併發數：50000
- 16臺客戶端：4C8G，無需外網，直接內網訪問
壓測環境準備
客戶端準備
- 客戶端下載安裝siege並修改參數配置
wget http://download.joedog.org/siege/siege-4.0.4.tar.gz \ && tar zxvf siege-4.0.4.tar.gz \ && cd siege-4.0.4 \ && ./configure \ && make \ && make install \ && siege -h sed -i "s/limit = 255/limit = 1000/g" ~/.siege/siege.conf 查看配置文件方式：siege -C | grep resource 4.0.4版本的siege配置文件在~/.siege/siege.conf siege客戶端線程數上限默認爲255，需要將其調大，以支持1000併發 siege -C | grep "thread limit" ==> 應該爲1000 - 修改linux系統打開文件數限制
ulimit -n 65535 PS：linux限制最大打開文件數爲$((2*20)),即爲1048576，多一個都不行 - 修改hosts到SLB
服務器準備
- 先複製一臺WEB服務器，測試人員採用hosts方式進行測試，開發人員對單機進行壓測，符合標準後做鏡像
- 將鏡像部署到32臺服務器
- 將所有服務器掛載到SLB
- 將所有服務器的日誌接入到日誌平臺
正式開始壓測
- 開發人員
使用xshell連接16臺客戶端 將壓測命令放入併發執行輸入框，同時執行 待壓測執行完畢，使用壓測統計命令，生成彙總壓測報告。 發給測試人員整理 - 運維人員將服務器性能監控報告發給測試人員
- 測試人員整理彙總，生成可視化壓測報告
壓測遇到的坑
- 第一次壓測的時候，php的session採用ocs，新部署的服務器網絡環境在vpc網絡中，造成ocs連接不上，現象是所有請求的響應時間都會大於1秒，由於php的memcache連接不上，壓測接口正常返回數據，運維人員沒有將錯誤日誌接入日誌平臺。所以只能上單臺服務器上進行測試，剛開始是在入口和結束的地方加入運行時長日誌，發現php運行時間只有0.004秒，但是nginx日誌卻是1.004秒，大半夜頭暈，找不到思路，後來直接上了xhprof進行性能分析，發現在性能瓶頸在Yii的Session::Open方法上，才發現是php沒有連接上ocs，看源碼，才知道Yii在打開會話失敗的時候只是記錄了一個錯誤日誌，由於運維沒接入錯誤日誌，所以也沒想到。後來修改了ocs代理，壓測響應時間正常。
- 第二次壓測，由於不想讓服務器通過代理訪問ocs，於是將session從ocs切換到redis。php的session使用Redis時，方式是在php.ini中配置的redis.so，發現這個組件有性能問題，一壓就掛了。後面改成使用yii2配置，使用yii2的組件（yii2使用unix stream socket，性能槓槓滴)，又發現Redis壓力上不去。後面把session的Redis和緩存的Redis分開才解決問題，懷疑是阿里雲集羣版redis和yii2的session中的操作有衝突，後面需要再確定。