性能測試介紹
指通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進行測試
對性能的認(rèn)識
---從用戶的角度：
---從開發(fā)的角度：
---從系統(tǒng)管理員的角度：
性能測試意義
????????研究表明，對于Web網(wǎng)站，多1秒的頁面延遲相當(dāng)于少了11%的PV，相當(dāng)于降低了16%的顧客滿意度。這就意味著：如果一個網(wǎng)站每天掙10萬元，那么一年下來，由于頁面加載速度慢1秒，可能導(dǎo)致?lián)p失25萬元的銷售額?; Compuware公司分析了超過150個網(wǎng)站和150萬個瀏覽頁面，發(fā)現(xiàn)頁面響應(yīng)時間從2秒增到10秒，會導(dǎo)致38%的瀏覽放棄率 。隨著各個企業(yè)的業(yè)務(wù)發(fā)展、用戶訪問量的增加，其服務(wù)系統(tǒng)承載的負(fù)荷也會隨著增加，系統(tǒng)性能的好壞將嚴(yán)重影響企業(yè)的利益，因此對于性能測試與優(yōu)化也越來越受業(yè)界的重視。
性能測試類型
基準(zhǔn)測試：在給系統(tǒng)施加較低壓力時，查看系統(tǒng)的運行狀況并記錄相關(guān)數(shù)做為基礎(chǔ)參考
負(fù)載測試：是指對系統(tǒng)不斷地增加壓力或增加一定壓力下的持續(xù)時間，直到系統(tǒng)的某項或多項性能指標(biāo)達(dá)到安全臨界值，例如某種資源已經(jīng)達(dá)到飽和狀態(tài)等 。
壓力測試：壓力測試是評估系統(tǒng)處于或超過預(yù)期負(fù)載時系統(tǒng)的運行情況，關(guān)注點在于系統(tǒng)在峰值負(fù)載或超出最大載荷情況下的處理能力。
穩(wěn)定性測試：在給系統(tǒng)加載一定業(yè)務(wù)壓力的情況下，使系統(tǒng)運行一段時間，以此檢測系統(tǒng)是否穩(wěn)定。
并發(fā)測試：測試多個用戶同時訪問同一個應(yīng)用、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題
性能測試基本概念
響應(yīng)時間
1.定義：從用戶發(fā)送一個請求到用戶接收到服務(wù)器返回的響應(yīng)數(shù)據(jù)這段時間就是響應(yīng)時間
2.關(guān)鍵路徑：下圖為一次http請求經(jīng)過的路徑，請求會經(jīng)過網(wǎng)絡(luò)發(fā)送到web服務(wù)器進行處理，如果需要操作DB，再由網(wǎng)絡(luò)轉(zhuǎn)發(fā)到數(shù)據(jù)庫進行處理，然后返回值給web服務(wù)器，web服務(wù)器最后把結(jié)果數(shù)據(jù)通過網(wǎng)絡(luò)返回給客戶端
3.計算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（網(wǎng)絡(luò)時間 + 應(yīng)用程序處理時間）
4.響應(yīng)時間-負(fù)載對應(yīng)關(guān)系：
圖中拐點說明：
（1）響應(yīng)時間突然增加
（2）意味著系統(tǒng)的一種或多種資源利用達(dá)到的極限
（3）通常可以利用拐點來進行性能測試分析與定位
吞吐量
1.定義：單位時間內(nèi)系統(tǒng)處理的客戶端請求的數(shù)量
2.計算單位：一般使用請求數(shù)／秒做為吞吐量的單位，也可以使用頁面數(shù)／秒表表示。 另外，從業(yè)務(wù)角度來說也可以使用 訪問人數(shù) /天 或 頁面訪問量／天 做為單位。
3.計算方法：Throughput = (number of requests) / (total time).
4.吞吐量-負(fù)載對應(yīng)關(guān)系：?
圖中拐點說明：
（1）吞吐量逐漸達(dá)到飽和
（2）意味著系統(tǒng)的一種或多種資源利用達(dá)到的極限
（3）通?？梢岳霉拯c來進行性能測試分析與定位
并發(fā)數(shù)
（1）并發(fā)用戶數(shù)：某一物理時刻同時向系統(tǒng)提交請求的用戶數(shù)，提交的請求可能是同一個場景或功能，也可以是不同場景或功能。
（2）在線用戶數(shù)：某段時間內(nèi)訪問系統(tǒng)的用戶數(shù)，這些用戶并不一定同時向系統(tǒng)提交請求
（3）系統(tǒng)用戶數(shù)：系統(tǒng)注冊的總用戶數(shù)據(jù)
三者之間的關(guān)系：系統(tǒng)用戶數(shù) >= 在線用戶數(shù) >= 并發(fā)用戶數(shù)
并發(fā)，QPS，響應(yīng)時間，三者之間重要的關(guān)系
QPS*T(s)約等于并發(fā)，約等于含義是在同數(shù)量級上
錯誤率
錯誤：一般就是實際的響應(yīng)數(shù)據(jù)不是期望得到的響應(yīng)數(shù)據(jù)
錯誤一般分為，請求異常(接口或環(huán)境問題)，業(yè)務(wù)異常(代碼或數(shù)據(jù)問題)
PV/UV
PV：Page View，訪問一個頁面，產(chǎn)生一個PV
UV：Unique Visitor，一個用戶訪問網(wǎng)站，產(chǎn)生一個UV
備注：1.每日每個網(wǎng)站的總PV量是形容一個網(wǎng)站規(guī)模的重要指標(biāo)
? ? ? ? ? ?2.作為一個獨立的用戶，訪問站點的所有頁面均算作一個UV
容量評估的公式：
第一步：先根據(jù)日活用戶數(shù)，計算所需的tps
計算原則：1.20%的高峰時間內(nèi)完成80%的日活用戶數(shù)的請求
? ? ? ? ? ? ? ? ? 2.為了降低風(fēng)險，一般設(shè)定的目標(biāo)是評估值的3-5倍
目標(biāo)tps的計算：
(日活用戶數(shù)*每個用戶在系統(tǒng)中產(chǎn)生的請求數(shù)*0.8)/(時間段*3600*0.2)*5
第二步：壓測現(xiàn)有系統(tǒng)的實際性能
結(jié)合目標(biāo)tps與現(xiàn)有系統(tǒng)的實際tps，即可估算整個系統(tǒng)所需要的服務(wù)器數(shù)目
例：用戶系統(tǒng)目標(biāo)tps-1000，現(xiàn)有的壓測結(jié)果是，單臺服務(wù)器用戶模塊的整體qps-500，故用戶模塊要想維持目標(biāo)日活需要至少2臺服務(wù)器
資源利用率
1.定義：指的是對不同系統(tǒng)資源的使用程度，通常以占用最大值的百分比來衡量
2.通常需要關(guān)注的服務(wù)器資源如下：
（1）CPU：就像人的大腦，主要負(fù)責(zé)相關(guān)事情的判斷以及實際處理的機制
（2）內(nèi)存：大腦中的記憶塊區(qū)，將眼睛，皮膚等收集到的信息記錄起來的地方，以供cpu進行判斷，但是是臨時的，訪問速度快，如果關(guān)機或斷電這里的數(shù)據(jù)會消失。
（3）磁盤IO：大腦中的記憶區(qū)塊，將重要的數(shù)據(jù)保存起來（永久保存，關(guān)機或斷電不會丟失，速度慢），以便將來再次使用這些數(shù)據(jù)。
（4）網(wǎng)絡(luò)/帶寬：單位時間內(nèi)從網(wǎng)絡(luò)中的某一點到另一點所能通過的數(shù)據(jù)量(BPS)
3. 資源利用-負(fù)載對應(yīng)關(guān)系：
圖中拐點說明：
（1）服務(wù)器某薦資源使用逐漸達(dá)到飽和
（2）通常可以利用拐點來進行性能測試分析與定位
命令：sar -u ALL -r -q -d -p -n DEV 2
CPU? ? all 表示統(tǒng)計信息為所有 CPU 的平均值?
%user 在用戶模式運行所使用 CPU百分比?
%nice 在用戶模式用于nice操作所使用 CPU百分比?
%system 在系統(tǒng)模式運行所使用 CPU 百分比?
%iowait 用于等待I/O操作所占用 CPU 百分比?
%steal 管理程序為另一個虛擬進程提供服務(wù)而等待, 占CPU 百分比
?%idle 空閑CPU占用的百分比
指標(biāo)
kbmemfree：服務(wù)器空閑的內(nèi)存
kbmemused：服務(wù)器使用的內(nèi)存
%memused：物理內(nèi)存使用率, 這個值是kbmemused和內(nèi)存總量(不包括swap)百分比
kbbuffers：塊設(shè)備(block device)所占用的緩存頁，包括直接讀寫塊設(shè)備、以及文件系統(tǒng)元數(shù)據(jù)(metadata)如SuperBlock所使用的緩存頁
kbcached：表示普通文件所占用的緩存頁
kbcommit：保證當(dāng)前系統(tǒng)所需要的內(nèi)存,即為了確保不溢出而需要的內(nèi)存(RAM+swap).
%commit：這個值是kbcommit與內(nèi)存總量(包括swap)的一個百分比
runq-sz：運行隊列的長度（等待運行的進程數(shù)）
plist-sz：進程列表中進程（processes）和線程（threads）的數(shù)量
ldavg-1：最后1 分鐘的系統(tǒng)平均負(fù)載（System load average）
ldavg-5：過去5 分鐘的系統(tǒng)平均負(fù)載
ldavg-15：過去15 分鐘的系統(tǒng)平均負(fù)載
DEV ：磁盤設(shè)備名稱
tps:? 每秒到物理磁盤的請求數(shù)
rd_sec/s:? 每秒從設(shè)備讀入的扇區(qū)數(shù)（1扇區(qū)=512字節(jié)）
wr_sec/s:? 每秒寫入設(shè)備的扇區(qū)數(shù)目
avgrq-sz:?? 平均每次設(shè)備I/O操作的數(shù)據(jù)大小（以扇區(qū)為單位）
avgqu-sz:?? 平均I/O隊列的長度
await:??? 從請求磁盤操作到系統(tǒng)完成處理的平均消耗時間,包括請求隊列等待時間,單位ms
svctm:?? 平均每次設(shè)備I/O 操作的服務(wù)時間（毫秒）
%util:???? 一秒中有百分之幾的時間用用于I/O操作
IFACE： 網(wǎng)絡(luò)接口設(shè)備
rxpck/s： 每秒接收的數(shù)據(jù)包數(shù)目??????????? txpck/s? ： 每秒發(fā)送的數(shù)據(jù)包數(shù)目
rxkB/s： 每秒接受的字節(jié)數(shù)?????????????????????? txkB/s ：每秒發(fā)送的字節(jié)數(shù)
rxcmp/s： 每秒接受的壓縮包數(shù)目?????????? txcmp/s ：每秒發(fā)送的壓縮包數(shù)目
rxmcst/s： 每秒接受的多播數(shù)據(jù)包數(shù)目
總結(jié)——
1.? us+sy參考值為80%，如果大于80%，說明可能存在CPU資源不足的情況
2.? %util若接近100%，表示磁盤產(chǎn)生I/O請求太多，I/O系統(tǒng)已經(jīng)滿負(fù)荷地在工作，該磁盤可能存在瓶頸
3. %memused參考值為98%，如果大于98%，說明可能存在內(nèi)存不足的情況
4. rxkB/s或txkB/s，如果是百兆網(wǎng)卡，參考值是12MB/s，如果是千兆網(wǎng)卡，參考值為120MB/s，如果是萬兆網(wǎng)卡，參考值為1.2GB/s，帶寬超過參考值，說明可能存在帶寬不足的情況
5. await的大小一般取決與svctm的值和I/O隊列長度以及I/O請求模式。如果svctm與await很接近，表示幾乎沒有I/O等待，磁盤性能很好；如果await的值遠(yuǎn)高于svctm的值，表示I/O隊列等待太長，可能就會導(dǎo)致運行的應(yīng)用程序變慢，則需要檢查程序或更換更快的磁盤
工具
常見的性能測試工具，如：Jmeter, Loadrunner, Apche AB,WRK, unixbench, ubench,iperf,fio,IxChariot等等，每種工具的優(yōu)缺點各異，目前我們常用的Jmter，上手快，接口測試的各種需求基本都能夠滿足。
報告
性能測試報告中，既要包含重要性能指標(biāo)的值，又要包含服務(wù)器負(fù)載的情況，如下圖，所示：
不僅要在報告中記錄好本次壓測的客戶端與服務(wù)器端的性能數(shù)據(jù)，而且還應(yīng)用在發(fā)性能報告的郵件中，明確的寫清楚，本次壓測的目的，環(huán)境，結(jié)論，存在的問題，風(fēng)險等，方便研發(fā)，產(chǎn)品，項目的相關(guān)人員閱讀。
瓶頸
1. 通過基準(zhǔn)數(shù)據(jù)判斷性能瓶頸?
基準(zhǔn)數(shù)據(jù)，就是指框架或者中間件的單服務(wù)的性能極限，如tomcat框架，在目前思源環(huán)境_2C4G_docker下的極限性能QPS_4w左右（apache-tomcat-7.0.85）Mysql的select空查詢，在目前思源環(huán)境_2C4G_docker下的極限性能QPS_1.8w左右（mysql-5.1.73），Nginx轉(zhuǎn)發(fā)能力,在目前思源環(huán)境_2C4G_docker下的極限性能QPS_3.6w左右（nginx version: nginx/1.5.9），基準(zhǔn)性能數(shù)據(jù)，為查找性能瓶頸提供一種判斷的基準(zhǔn)，如，在制定基于tomcat框架的接口性能目標(biāo)時，其值應(yīng)該低于4w的qps，才比較合理；測試調(diào)用sql查詢的接口，如果性能已達(dá)1.5w左右，那基本也沒有調(diào)優(yōu)空間了；如果有需求nginx轉(zhuǎn)發(fā)能力要達(dá)到5w，則就要優(yōu)先考慮框架配置調(diào)優(yōu)。
tomcat框架-2C4Gdocker的基準(zhǔn)性能：QPS_4w(apache-tomcat-7.0.85)
http://172.28.34.98:8080/docs/tomcat.html
tomcat框架-2C4Gdocker的基準(zhǔn)性能：QPS_4w(apache-tomcat-7.0.85)
http://172.28.34.98:8080/docs/tomcat.html
Mysql的select空查詢- 2C4G docker的基準(zhǔn)性能:QPS_1.7w
jdbc:mysql://172.28.34.98/jizhuntest test/test(mysql-5.1.73)
Nginx框架-2C4G docker的基準(zhǔn)性能：QPS_3.6w (nginx/1.5.9)
http://172.28.34.98:8081/helloword.html
2. 通過服務(wù)器資源判斷性能瓶頸
CPU使用率99.5%
千兆帶寬滿
內(nèi)存不足
磁盤I/O
3. 通過APM協(xié)助判斷性能瓶頸
具體哪行代碼的問題
數(shù)據(jù)庫的SQL語句問題
GC頻繁
第三方調(diào)用
網(wǎng)絡(luò)延時問題
jprofile可看到方法的調(diào)用層次，cpu熱點方法等
總結(jié)：
1. 通過框架或者中間件的基準(zhǔn)性能數(shù)據(jù)，可界定性能數(shù)據(jù)的上線
2. 在定位性能瓶頸前一定要清楚請求的整個鏈路拓?fù)?，通過監(jiān)控拓?fù)涓鱾€環(huán)節(jié)服務(wù)器的負(fù)載情況，可以進一步的確定到底哪個環(huán)節(jié)是性能瓶頸
3. 可以借助APM，進行代碼級別的定位性能瓶頸的具體原因
4.APM也不是萬能的，很多情況下，也是會發(fā)生漏監(jiān)控的情況，所以性能瓶頸的定位也不能夠完全依賴APM
其它常用概念
TPS：Transactions Per Second，每秒事務(wù)數(shù)
思考時間：用戶每個操作后的暫停時間，或者叫操作之間的間隔時間，此時間內(nèi)是不對服務(wù)器產(chǎn)生壓力的
點擊數(shù)：每秒鐘用戶向WEB服務(wù)器提交的HTTP請求數(shù)。 這個指標(biāo)是WEB應(yīng)用特有的一個指標(biāo):WEB應(yīng)用是”請求-響應(yīng)”模式,用戶發(fā)出一次申請,服務(wù)器就要處理一次，所以點擊是WEB應(yīng)用能夠處理的交易的最小單位。 如果把每次點擊定義為一個交易，點擊率和TPS就是一個概念。容易看出，點擊率越大，對服務(wù)器的壓力越大。點擊率只是一個性能參考指標(biāo)，重要的是分析點擊時產(chǎn)生的影響。 需要注意的是，這里的點擊并非指鼠標(biāo)的一次單擊操作，因為在一次單擊操作中，客戶端可能向服務(wù)器發(fā)出多個HTTP請求.
性能測試模型
曲線拐點模型
?
X軸代表并發(fā)用戶數(shù)，Y軸代表資源利用率、吞吐量、響應(yīng)時間。X軸與Y軸區(qū)域從左往右分別是輕壓力區(qū)、重壓力區(qū)、拐點區(qū)。
隨著并發(fā)用戶數(shù)的增加，在輕壓力區(qū)的響應(yīng)時間變化不大，比較平緩，進入重壓力區(qū)后呈現(xiàn)增長的趨勢，最后 進入拐點區(qū)后傾斜率增大，響應(yīng)時間急劇增加。
接著看吞吐量，隨著并發(fā)用戶數(shù)的增加，吞吐量增加，進入重壓力區(qū)后逐步平穩(wěn)，到達(dá)拐點區(qū)后急劇下降，說明系統(tǒng)已經(jīng)達(dá)到了處理極限，有點要扛不住的感覺。
同理，隨著并發(fā)用戶數(shù)的增加，資源利用率逐步上升，最后達(dá)到飽和狀態(tài)。
最后，把所有指標(biāo)融合到一起來分析，隨著并發(fā)用戶數(shù)的增加，吞吐量與資源利用率增加，說明系統(tǒng)在積極處理，所以響應(yīng)時間增加得并不明顯，處于比較好的狀態(tài)。但隨著并發(fā)用戶數(shù)的持續(xù)增加，壓力也在持續(xù)加大，吞吐量與資源利用率都達(dá)到了飽和，隨后吞吐量急劇下降，造成響應(yīng)時間急劇增長。輕壓力區(qū)與重壓力區(qū)的交界點是系統(tǒng)的最佳并發(fā)用戶數(shù)，因為各種資源都利用充分，響應(yīng)也很快；而重壓力區(qū)與拐點區(qū)的交界點就是系統(tǒng)的最大并發(fā) 用戶數(shù)，因為超過這個點，系統(tǒng)性能將會急劇下降甚至崩潰。
地鐵模型
假設(shè)：
某地鐵站進站只有3個刷卡機。
人少的情況下，每位乘客很快就可以刷卡進站，假設(shè)進站需要1s。
乘客耐心有限，如果等待超過30min，就暴躁、嘮叨，甚至放棄。
場景一：只有1名乘客進站時，這名乘客可以在1s的時間內(nèi)完成進站，且只利用了一臺刷卡機，剩余2臺等待著。
場景二：只有2名乘客進站時，2名乘客仍都可以在1s的時間內(nèi)完成進站，且利用了2臺刷卡機，剩余1臺等待著。
場景三：只有3名乘客進站時，3名乘客還能在1s的時間內(nèi)完成進站，且利用了3臺刷卡機，資源得到充分利用。
場景四：A、B、C三名乘客進站，同時D、E、F乘客也要進站，因為A、B、C先到，所以D、E、F乘客需要排隊。
那么，A、B、C乘客進站時間為1s，而D、E、F乘客必須等待1s，所以他們3位在進站的時間是2s。
場景五：假設(shè)這次進站一次來了9名乘客，有3名的“響應(yīng)時間”為1s，有3名的“響應(yīng)時間”為2s（等待1s+進站1s）， 還有3名的“響應(yīng)時間”為3s（等待2s+進站1s）。
場景六：如果地鐵正好在火車站，每名乘客都拿著大小不同的包，包太大導(dǎo)致卡在刷卡機堵塞，每名乘客的進站時 間就會又不一樣。刷卡機有加寬的和正常寬度的兩種類型，那么拿大包的乘客可以通過加寬的刷卡機快速進站（增 加帶寬）。
場景七：進站的乘客越來越多，3臺刷卡機已經(jīng)無法滿足需求，為了減少人流的積壓，需要再多開幾個刷卡機，增 加進站的人流與速度（提升TPS、增大連接數(shù)）。
場景八：到了上班高峰時間了，乘客數(shù)量上升太快，現(xiàn)有的進站措施已經(jīng)無法滿足，越來越多的人開始抱怨、 擁擠，情況越來越糟。單單增加刷卡機已經(jīng)不行了，此時的乘客就相當(dāng)于“請求”，乘客不是在地鐵進站排隊，就是 在站臺排隊等車，已經(jīng)造成嚴(yán)重的“堵塞”，那么增加發(fā)車頻率（加快應(yīng)用服務(wù)器、數(shù)據(jù)庫的處理速度）、增加車廂數(shù)量（增加內(nèi)存、增大吞吐量）、增加線路（增加服務(wù)的線程）、限流、分流等多種措施便應(yīng)需而生。
備注：以上內(nèi)容包含網(wǎng)上收集整理以及公司培訓(xùn)內(nèi)容整理。
