跑穩(wěn)定性之前要檢查的環(huán)境

1、壓力機(jī)磁盤(pán)空間（因?yàn)榕芊€(wěn)定性過(guò)程中生成的result文件的數(shù)據(jù)不斷增加，如果壓力機(jī)磁盤(pán)空間不夠就會(huì)導(dǎo)致壓力停止）

2、清空服務(wù)器日志，日志改成error模式，檢查服務(wù)器空間大小。定時(shí)任務(wù)需要定時(shí)刪除日志

3、查看數(shù)據(jù)庫(kù)表空間是否足夠

4、清空gc日志（方便觀察穩(wěn)定性的 gc情況）

5、如果執(zhí)行過(guò)程中會(huì)生成數(shù)據(jù)并且數(shù)據(jù)保存在磁盤(pán)上，則需要考慮寫(xiě)個(gè)定時(shí)任務(wù)定時(shí)刪除數(shù)據(jù)（如果這些數(shù)據(jù)可刪除的情況下）

6、穩(wěn)定性測(cè)試目的：HPJmeter分析日志是否能正?；厥眨艿脑捳f(shuō)明不存在內(nèi)存溢出問(wèn)題。gc時(shí)間百分比和fullgc時(shí)間百分比不超過(guò)5%則是正常的

批處理

1、了解生產(chǎn)環(huán)境上的數(shù)據(jù)是怎么分布的，才能在測(cè)試環(huán)境更好的模擬

2、從數(shù)據(jù)庫(kù)上驗(yàn)證結(jié)果，哪些表的哪些字段改變了，數(shù)據(jù)增加了還是減少了多少，這個(gè)值與預(yù)期的是否一致，用sql記錄跑批前后的數(shù)據(jù)量，驗(yàn)證數(shù)據(jù)的流向是否符合業(yè)務(wù)邏輯

3、批處理的處理流程，數(shù)據(jù)先到哪個(gè)表，再到哪個(gè)表，表的數(shù)據(jù)要依賴(lài)哪個(gè)表

4、例如存儲(chǔ)加工：也就是報(bào)表跑數(shù)，報(bào)表跑數(shù)需要原系統(tǒng)表里有數(shù)據(jù)才能跑報(bào)表跑數(shù)，報(bào)表卸數(shù)的話是要報(bào)表結(jié)果表里有數(shù)據(jù)才能卸數(shù)

5、數(shù)據(jù)不夠怎么造數(shù)

6、批處理測(cè)試關(guān)注批處理時(shí)間、批處理效率、批處理總量

波動(dòng)

1、穩(wěn)定性運(yùn)行過(guò)程中tps掉了一個(gè)坑，15分鐘后恢復(fù)正常。檢查波動(dòng)那個(gè)時(shí)間段后臺(tái)是否有在做批處理。如果是，這波動(dòng)是正常的（批處理導(dǎo)致cpu增大，tps減少）

腳本報(bào)錯(cuò)

1、壓力執(zhí)行過(guò)程中剛開(kāi)始沒(méi)報(bào)錯(cuò)，后來(lái)持續(xù)報(bào)錯(cuò)

2、檢查日志是否滿了或者表空間滿了

3、是否是數(shù)據(jù)太多，返回結(jié)果太多造成的

穩(wěn)定性過(guò)程中有支交易的響應(yīng)時(shí)間越跑越高

1、檢查該交易的最高響應(yīng)時(shí)間是否超時(shí)，如果超時(shí)則要優(yōu)化，如果不超時(shí)，可否優(yōu)化

2、單跑該交易，觀察響應(yīng)時(shí)間是否越跑越高

3、檢查該交易是要處理數(shù)據(jù)還是查詢(xún)數(shù)據(jù)，依賴(lài)哪些表，是不是依賴(lài)的表的數(shù)據(jù)增加才導(dǎo)致該交易響應(yīng)時(shí)間增加的

4、重測(cè)場(chǎng)景，去掉會(huì)增加數(shù)據(jù)的交易，看該交易響應(yīng)時(shí)間是否增加

5、如果能優(yōu)化最好，如果不能優(yōu)化，應(yīng)該在測(cè)試報(bào)告中說(shuō)明

6、通過(guò)分析得出該交易響應(yīng)時(shí)間的增長(zhǎng)是因?yàn)槠渌淼臄?shù)據(jù)增長(zhǎng)造成的，生產(chǎn)上每天凌晨都會(huì)清理一定的數(shù)據(jù)，所以該交易的響應(yīng)時(shí)間增長(zhǎng)不會(huì)造成生產(chǎn)超時(shí)的存在

腳本調(diào)試

1、根據(jù)腳本模板替換報(bào)文，到日志中去查找對(duì)應(yīng)的報(bào)文

2、編譯腳本看是否存在語(yǔ)法錯(cuò)誤，如果有，檢查語(yǔ)法和報(bào)文的格式

3、運(yùn)行腳本看是否存在錯(cuò)誤，如果有，查看應(yīng)用服務(wù)器日志，具體是什么原因報(bào)的錯(cuò)日志都有顯示

4、常見(jiàn)的錯(cuò)誤是數(shù)據(jù)庫(kù)里沒(méi)有數(shù)據(jù)，這時(shí)需要根據(jù)錯(cuò)誤提示去數(shù)據(jù)庫(kù)修改數(shù)據(jù)（耗費(fèi)時(shí)間也是最多的）

5、保證要測(cè)試交易數(shù)據(jù)庫(kù)表里的數(shù)據(jù)足夠（數(shù)據(jù)跟生產(chǎn)環(huán)境一致）

6、檢查哪些字段需要參數(shù)化，找到該字段對(duì)應(yīng)的表，從數(shù)據(jù)庫(kù)里查詢(xún)需要參數(shù)化的數(shù)據(jù)（耗費(fèi)時(shí)間也很多，你需要知道字段對(duì)應(yīng)的表和數(shù)據(jù)的流向才能正確的拼湊出對(duì)應(yīng)的sql語(yǔ)句，表的關(guān)聯(lián)很多）

負(fù)載測(cè)試超時(shí)

1、從最簡(jiǎn)單的地方開(kāi)始分析：檢查壓力機(jī)、應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器是否存在硬件瓶頸，是否存在網(wǎng)絡(luò)瓶頸

2、檢查該交易對(duì)應(yīng)的表的數(shù)據(jù)是否過(guò)多，超時(shí)大部分是數(shù)據(jù)庫(kù)原因造成的

3、重壓超時(shí)的交易，啟動(dòng)awr監(jiān)控（數(shù)據(jù)庫(kù)）

4、分析awr報(bào)告，查看哪些表沒(méi)有索引、全表掃描等。如果有索引，查看是否有的數(shù)據(jù)沒(méi)走索引

5、如果走索引，檢查該交易是否查詢(xún)的字段太多（比如：業(yè)務(wù)要求一次性處理365條數(shù)據(jù)，操作比較大）

6、參數(shù)化數(shù)據(jù)太少了，數(shù)據(jù)庫(kù)有行鎖導(dǎo)致響應(yīng)時(shí)間超時(shí)，加上足夠的參數(shù)化數(shù)據(jù)即可

7、參數(shù)化數(shù)據(jù)太少了，引起對(duì)數(shù)據(jù)庫(kù)表的掙用，造成死鎖，所以報(bào)超時(shí)錯(cuò)誤，加上足夠的參數(shù)化數(shù)據(jù)即可

8、數(shù)據(jù)庫(kù)表鎖、行鎖、鎖等待、死鎖都會(huì)造成超時(shí)（數(shù)據(jù)庫(kù)的用對(duì)應(yīng)的sql查詢(xún)是否有這些問(wèn)題存在）

交易處理能力下降

1、穩(wěn)定性測(cè)試過(guò)程中，發(fā)現(xiàn)整體交易處理能力隨著時(shí)間的推移呈逐步下降趨勢(shì)。經(jīng)過(guò)對(duì)測(cè)試結(jié)果中各交易進(jìn)行排查，確定導(dǎo)致tps下降的交易只有一只，該交易在測(cè)試模型中占比達(dá)到45%，當(dāng)該交易響應(yīng)時(shí)間逐步增長(zhǎng)后，其交易能力呈反比下降，最終導(dǎo)致整體處理能力下降

2、分析服務(wù)器日志，統(tǒng)計(jì)該交易在服務(wù)器端的時(shí)間基本都是穩(wěn)定狀態(tài)，并且沒(méi)有發(fā)現(xiàn)堆內(nèi)存溢出情況，由此可排除程序問(wèn)題

3、使用jconsole進(jìn)程監(jiān)控，發(fā)現(xiàn)進(jìn)程在運(yùn)行過(guò)程中存在頻繁加載、卸載類(lèi)的情況

4、正常情況下Java進(jìn)程是不應(yīng)該頻繁加載和卸載類(lèi)的。由于測(cè)試腳本調(diào)用引用的Java框架使用了大量的類(lèi)，當(dāng)Java內(nèi)存中的永久保持區(qū)過(guò)小時(shí)，就會(huì)導(dǎo)致經(jīng)常被引用的類(lèi)頻繁加載和卸載。由于堆內(nèi)存過(guò)小，頻繁new對(duì)象時(shí)容易產(chǎn)生大量?jī)?nèi)存碎片，從而導(dǎo)致new對(duì)象時(shí)效率逐步降低

5、解決方法：擴(kuò)大-XX:MaxPermSize值

6、重新執(zhí)行測(cè)試，整個(gè)測(cè)試過(guò)程中該交易運(yùn)行平穩(wěn)，未出現(xiàn)響應(yīng)時(shí)間增長(zhǎng)，處理能力下降的情況

PS：堆內(nèi)存大小到低需要配置多少并沒(méi)有一個(gè)固定標(biāo)準(zhǔn)，并不一定越大越好，需要根據(jù)被測(cè)交易特性，并發(fā)數(shù)量以及壓力機(jī)配置等進(jìn)行不斷測(cè)試分析后再進(jìn)行相應(yīng)的合理劃分

Java占用內(nèi)存分析

很多人誤認(rèn)為-Xmx和-Xms參數(shù)指定的大小就是程序占用的內(nèi)存，實(shí)際只是Java堆對(duì)象將會(huì)占用的內(nèi)存。堆只是影響Java程序占用內(nèi)存大小的一個(gè)因素。要更好的理解你的Java程序會(huì)占用多大的內(nèi)存需要先了解以下因素：

對(duì)象（objects）

類(lèi)（classes）

線程（threads）

本地?cái)?shù)據(jù)接口（native data structures）

本地代碼（native code）

這些因素對(duì)內(nèi)存的影響又會(huì)隨著城鄉(xiāng)、環(huán)境和平臺(tái)的變化而變化。想要精確的計(jì)算總的內(nèi)存大小并不是那么容易，因?yàn)槟阒荒芸刂贫汛笮。?Xmx）、類(lèi)占用的內(nèi)存（-XX:MaxPermSize）、線程棧（-Xss控制每個(gè)線程占用的內(nèi)存），但如果棧太小時(shí)會(huì)導(dǎo)致棧溢出。所以計(jì)算公式為：（-Xmx）+（-XX:MaxPermSize）+線程數(shù)*（-Xss）+其他內(nèi)存

其他內(nèi)存取決于本地代碼占用內(nèi)存，它大約占JVM內(nèi)存的5%左右

線程池占滿

1、監(jiān)控tomcat中間件是為了監(jiān)控線程池的使用情況，如果tomcat里還配置了數(shù)據(jù)庫(kù)連接池也要監(jiān)控?cái)?shù)據(jù)庫(kù)連接池的使用情況。假如配置了300個(gè)線程池，那么如果監(jiān)控到這300個(gè)線程池都屬于繁忙狀態(tài)，那說(shuō)明線程池不夠用了，后面的請(qǐng)求都屬于排隊(duì)狀態(tài)，排隊(duì)需要等待，會(huì)導(dǎo)致響應(yīng)時(shí)間增長(zhǎng)。但如果配置的線程池太大，則會(huì)浪費(fèi)資源。所以需要減少不必要的線程池的浪費(fèi)

2、通過(guò)通過(guò)manager status監(jiān)控tomcat，修改tomcat/conf里的tomcat-users.xml進(jìn)行配置，配置角色、用戶名、密碼，重啟tomcat

3、訪問(wèn)http://localhost:8080/manager/status進(jìn)行監(jiān)控

4、acceptCount="300"，指的是當(dāng)線程數(shù)達(dá)到maxThreads后，后續(xù)請(qǐng)求會(huì)被放入一個(gè)等待隊(duì)列，這個(gè)acceptCount是這個(gè)隊(duì)列的大小，如果這個(gè)隊(duì)列也滿了就直接refuse? connection

場(chǎng)景1：接受一個(gè)請(qǐng)求，此時(shí)tomcat啟動(dòng)的線程數(shù)還沒(méi)有達(dá)到maxThreads，tomcat會(huì)啟動(dòng)一個(gè)線程來(lái)處理該請(qǐng)求

場(chǎng)景2：接受一個(gè)請(qǐng)求，此時(shí)tomcat啟動(dòng)的線程數(shù)已經(jīng)達(dá)到了maxThreads，tomcat把該請(qǐng)求放入隊(duì)列，等待空閑了再來(lái)處理

場(chǎng)景3：接受一個(gè)請(qǐng)求，此時(shí)tomcat啟動(dòng)的線程數(shù)已經(jīng)達(dá)到了maxThreads，且acceptCount也達(dá)到了最大，此時(shí)tomcat會(huì)拒絕此次請(qǐng)求，返回refuse connection錯(cuò)誤

5、調(diào)整tomcat最大連接數(shù)，可以增加maxThreads和acceptCount，并且使acceptCount大于等于maxThreads

6、maxTreads的值應(yīng)該根據(jù)流量的大小，如果值過(guò)低，將沒(méi)有足夠的線程來(lái)處理所有的請(qǐng)求，請(qǐng)求將進(jìn)入等待狀態(tài)，只有當(dāng)一個(gè)處理線程釋放后才被處理；如果設(shè)置的太大，tomcat的啟動(dòng)將花費(fèi)更多的時(shí)間。所以該值需要實(shí)際測(cè)試分析得出，可通過(guò)前面講的managerstatus監(jiān)控頁(yè)面得到。切記不能一味的擴(kuò)大該值，瓶頸無(wú)法突破時(shí)，可以使用tomcat集群來(lái)提升性能

系統(tǒng)負(fù)載總是很高

1、系統(tǒng)運(yùn)行一段時(shí)間后發(fā)現(xiàn)服務(wù)器的負(fù)載總是很高，而且后臺(tái)出現(xiàn)錯(cuò)誤日志。臨時(shí)解決方案：重啟機(jī)器，但是過(guò)了一段時(shí)間之后發(fā)現(xiàn)負(fù)載還是很高

2、不壓測(cè)時(shí)看系統(tǒng)負(fù)載高不高，如果還高那就是系統(tǒng)本身有壓力，看是什么導(dǎo)致負(fù)載高

LoadRunner響應(yīng)時(shí)間和用戶體驗(yàn)時(shí)間不一致

1、測(cè)試過(guò)程中發(fā)現(xiàn)loadrunner測(cè)試響應(yīng)時(shí)間和客戶端實(shí)際的用戶體驗(yàn)時(shí)間不一致的現(xiàn)象，客戶體驗(yàn)時(shí)間遠(yuǎn)遠(yuǎn)超過(guò)loadrunner測(cè)試的響應(yīng)時(shí)間

2、分析：用戶通過(guò)瀏覽器訪問(wèn)web服務(wù)器時(shí)，時(shí)間包括用戶感應(yīng)時(shí)間、瀏覽器處理時(shí)間、網(wǎng)絡(luò)傳輸延時(shí)和后臺(tái)服務(wù)處理時(shí)間。而loadrunner測(cè)試響應(yīng)時(shí)間不包括瀏覽器的JS文件解析執(zhí)行、渲染、以及人眼識(shí)別時(shí)間，只包括網(wǎng)絡(luò)延時(shí)和后臺(tái)服務(wù)處理時(shí)間。因?yàn)閘oadrunner主要是用來(lái)測(cè)試后臺(tái)服務(wù)器性能的

3、一般情況下loadrunner測(cè)試響應(yīng)時(shí)間都會(huì)小于用戶實(shí)際體驗(yàn)時(shí)間

如果測(cè)試目的要求獲取用戶體驗(yàn)時(shí)間，則需要在loadrunner測(cè)試時(shí)間的基礎(chǔ)上，考慮添加誤差因子

如果用戶實(shí)際體驗(yàn)時(shí)間遠(yuǎn)大于loadrunner測(cè)試響應(yīng)時(shí)間，則需要重點(diǎn)分析排查JS解析執(zhí)行、渲染、布局等問(wèn)題

如果loadrunner測(cè)試響應(yīng)時(shí)間較長(zhǎng)，則分析是什么原因?qū)е鲁瑫r(shí)