開始性能測試前需要了解的內(nèi)容：

1、項目具體需求。

2、指標(biāo)：響應(yīng)時間在多少以內(nèi)，并發(fā)數(shù)多少，tps多少，總tps多少，穩(wěn)定性交易總量多少，事務(wù)成功率，交易波動范圍，穩(wěn)定運行時長，資源利用率，測哪些交易，哪些接口,測試哪些場景。

3、環(huán)境：生產(chǎn)環(huán)境服務(wù)器數(shù)量，測試環(huán)境服務(wù)器數(shù)量，按照資源配比得出測試指標(biāo)。

4、協(xié)議：系統(tǒng)用什么協(xié)議進(jìn)行通訊。

5、壓力機(jī)數(shù)量：如果并發(fā)用戶數(shù)太多，需要把壓力發(fā)到不同的壓力機(jī)，不然可能會存在壓力機(jī)瓶頸問題，導(dǎo)致tps和響應(yīng)時間抖動。

6、交易占比：分析線上日志得出tps占比。

7、系統(tǒng)架構(gòu)：請求流經(jīng)過哪些環(huán)節(jié)，壓測時監(jiān)控這些環(huán)節(jié)。

測試：

1、基準(zhǔn)：一個用戶迭代100次，關(guān)注響應(yīng)時間，事務(wù)成功率100%。

2、負(fù)載：10個用戶跑10分鐘，關(guān)注響應(yīng)時間，事務(wù)成功率100%。

3、容量：估算一個總tps，根據(jù)公式計算出每個交易的pacing和vu，獲取系統(tǒng)最大處理能力（最優(yōu)容量），再令外測出三個梯度作為對比（兩組小于最優(yōu)容量，一組大于最優(yōu)容量），四組容量VU等差，tps等差，對比每組容量實際占比和測試占比（越接近越能模擬真實場景），關(guān)注響應(yīng)時間，總tps，tps，事務(wù)成功率，AP cpu利用率，DB cpu利用率，線程死鎖，數(shù)據(jù)庫死鎖。

       其中響應(yīng)時間應(yīng)小于負(fù)載測試時間，總tps應(yīng)約等于預(yù)估總tps（相差不超過10是正常的），每個交易的tps應(yīng)接近預(yù)估總tps*占比，事務(wù)成功率100%，AP cpu小于60%，DB cpu小于80%。dump線程棧檢測是否有線程死鎖，查看數(shù)據(jù)庫日志看是否有數(shù)據(jù)庫死鎖。

4、穩(wěn)定性：采取最優(yōu)容量的80%作為壓力持續(xù)運行24小時，觀察系統(tǒng)長時間運行的性能表現(xiàn)，關(guān)注響應(yīng)時間，tps，總tps，事務(wù)成功率，交易總數(shù)，觀察是否有內(nèi)存溢出（堆溢出，棧溢出，持久代溢出），cpu利用率是否達(dá)標(biāo)，mem是否不持續(xù)增長，是否能正常觸發(fā)fullgc，gc時間，gc頻率， fullgc時間，fullgc頻率（重點關(guān)注，JVM調(diào)優(yōu)就是為了減少fullgc頻率）。 ;

監(jiān)控：

容量測試和穩(wěn)定性測試時啟動nmon監(jiān)控。

壓測中遇到的性能問題及解決辦法：

一、容量測試過程中cpu過高

1、用vmstat實時監(jiān)控cpu使用情況。很小的壓力AP cpu卻到了80%多，指標(biāo)是不能超過60%。

2、分析是use cpu過高還是sys cpu過高，常見的是use cpu使用過高。

3、如果是sys cpu使用過高，先把消耗cpu最多的進(jìn)程找出來（top命令），再找到該線程下消耗cpu過高的是哪幾個線程，再把該線程轉(zhuǎn)換成16進(jìn)制，再用jstack命令來dump線程棧，看這個線程棧在調(diào)用什么東西導(dǎo)致use cpu過高。 

二、內(nèi)存溢出（堆溢出、棧溢出、持久代溢出）

1、堆內(nèi)存溢出

1)穩(wěn)定性壓測一段時間后，LR報錯，日志報java.lang.OutOfMemoryError.Java heap space。

2)用jmap -histo pid命令dump堆內(nèi)存使用情況，查看堆內(nèi)存排名前20個對象，看是否有自己應(yīng)用程序的方法，從最高的查起，如果有則檢查該方法是什么原因造成堆內(nèi)存溢出。

3)如果前20里沒有自己的方法，則用jmap -dump來dump堆內(nèi)存，在用MAT分析dump下來的堆內(nèi)存，分析導(dǎo)出內(nèi)存溢出的方法。

4)如果應(yīng)用程序的方法沒有問題，則需要修改JVM參數(shù)，修改xms，xmx，調(diào)整堆內(nèi)存參數(shù)，一般是增加堆內(nèi)存。

2、棧內(nèi)存溢出

1)穩(wěn)定性壓測一段時間后，LR報錯，日志報Java.Lang.StackOverflowError。

2)修改jvm參數(shù)，將xss參數(shù)改大，增加棧內(nèi)存。

3)棧溢出一定是做批量操作引起的，減少批處理數(shù)據(jù)量。

3、持久代溢出

1)穩(wěn)定性壓測一定時間后，日志報Java.Lang.OutOfMenoryError.PermGen Space。

2)這種原因是由于類、方法描述、字段描述、常量池、訪問修飾符等一些靜態(tài)變量太多，將持久代占滿導(dǎo)致持久代溢出。

3)修改jvm配置，將XX:MaxPermSize=256參數(shù)調(diào)大。盡量減少靜態(tài)變量。

三、線程死鎖

1、容量測試壓測一段時間后，LR報連接超時。

2、造成這種現(xiàn)象的原因很多，比如帶寬不夠，中間件線程池不夠用，數(shù)據(jù)庫連接池不夠，連接數(shù)占滿等都會造成連接不上而報超時錯誤。

3、jstack命令dump線程棧，搜索線程棧里有沒有block，如果有的話就是線程死鎖，找到死鎖的線程，分析對應(yīng)的代碼。

四、數(shù)據(jù)庫死鎖

1、容量測試壓測一段時間后，LR報連接超時。

2、造成這種現(xiàn)象的原因很多，比如帶寬不夠，中間件線程池不夠用，數(shù)據(jù)庫連接池不夠，連接數(shù)占滿等都會造成連接不上而報超時錯誤。

3、數(shù)據(jù)庫日志中搜索block，能搜到block的話就是存在數(shù)據(jù)庫死鎖，找到日志，查看對應(yīng)的sql，優(yōu)化造成死鎖的sql。

五、數(shù)據(jù)庫連接池不釋放

1、容量測試壓測一段時間后，LR報連接超時。

2、造成這種現(xiàn)象的原因很多，比如帶寬不夠，中間件線程池不夠用，數(shù)據(jù)庫連接池不夠，連接數(shù)占滿等都會造成連接不上而報超時錯誤。

3、去數(shù)據(jù)庫查看應(yīng)用程序到數(shù)據(jù)庫的連接有多少個（ show full processlist），假如應(yīng)用程序里面配置的數(shù)據(jù)庫連接為30，在數(shù)據(jù)庫查看應(yīng)用程序到數(shù)據(jù)庫的連接也是30，則表示連接池占滿了。將配置改成90試試，去數(shù)據(jù)庫看如果連接到了90，則可以確定是數(shù)據(jù)庫連接池不釋放導(dǎo)致的。查看代碼，數(shù)據(jù)庫連接部分是不是有創(chuàng)建連接但是沒有關(guān)閉連接的情況?；揪褪沁@種情況導(dǎo)致的，修改代碼即可。

六、TPS上不去

1、壓力大的時候tps頻繁抖動，導(dǎo)致總tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）。

2、pacing設(shè)置太小也會導(dǎo)致tps上不去，對抖動大的交易多增加點用戶即可。

3、tps抖動，單壓抖動大的交易，發(fā)現(xiàn)很平穩(wěn)，這時懷疑是不是壓力太大導(dǎo)致，所以發(fā)容量的時候把壓力最大的那只交易分到其他壓力機(jī)，然后發(fā)現(xiàn)tps不抖動了。注意：多臺壓力機(jī)只影響tps抖動，不會影響服務(wù)器的cpu。

4、看響應(yīng)時間有沒有超時，看用戶數(shù)夠不夠。

七、服務(wù)器壓力不均衡（相差1%-2%是正常的）

1、跑最優(yōu)容量的時候，四臺AP只有一臺cpu超過60%，其他三臺都在60%以下。

2、查看服務(wù)器是否有定時任務(wù)。

3、查看是否存在壓力機(jī)瓶頸。

4、是否存在帶寬瓶頸（局域網(wǎng)不存在此問題）。

5、查看部署的版本，配置是否一樣。

6、可能別人也在用這些AP，因為同一臺物理機(jī)上有很多虛擬機(jī)，因為別人先用，資源被別人先占了。

八、fullgc時間太長

1、跑容量和穩(wěn)定性的時候，出現(xiàn)LR報請求超時錯誤，查看后臺日志是fullgc了，看LR幾點報的錯和日志里fullgc的時間是否對應(yīng)，fullgc會暫停整個應(yīng)用程序，導(dǎo)致LR前端沒響應(yīng)，所以報錯，這時可以減少old代內(nèi)存，從而減少fullgc時間，減少fullgc時間LR就不會報錯，讓用戶幾乎感覺不到應(yīng)用程序暫停。

2、四臺AP輪流著full gc（部分server fullgc，其他server也會fullgc），這時可以制定策略讓不同的server不同時fullgc，或者等夜間交易量少時寫定時任務(wù)重啟服務(wù)。

注意：

服務(wù)器日志為error下測試。

服務(wù)啟動后幾分鐘內(nèi)發(fā)壓壓力會很大，最好是服務(wù)啟動兩三分鐘后再開始跑壓力。

本文轉(zhuǎn)自（）

查看更多軟件測試資訊、產(chǎn)品、教程>>>>

您也可了解更多>>