性能測試的概念是什么夫晌，基本目的是什么，我想大家都基本清楚谦去，不作詳述慷丽，總之，性能測試只是測試過程中的一種方式鳄哭，幫助我們的功能更好的運(yùn)行要糊，如果功能測試是可用，易用妆丘，滿足需求锄俄、用戶使用為目的，性能測試無非就是讓這些目的更流暢勺拣。沒有什么專業(yè)的概念奶赠，無非實(shí)現(xiàn)兩個(gè)字：好用！
所以药有，性能測試這種測試方式在發(fā)生過程中毅戈，其中一個(gè)過渡性的工作，就是對執(zhí)行過程中的問題愤惰，進(jìn)行定位苇经，對功能的定位，對負(fù)載的定位宦言，最重要的扇单，當(dāng)然就是問題中說的“瓶頸”，接觸性能測試不深奠旺，更非專家蜘澜，自己的理解施流，瓶頸產(chǎn)生在以下幾方面：
1、網(wǎng)絡(luò)瓶頸鄙信，如帶寬瞪醋，流量等形成的網(wǎng)絡(luò)環(huán)境
2、應(yīng)用服務(wù)瓶頸扮碧，如中間件的基本配置趟章，CACHE等
3、系統(tǒng)瓶頸慎王，這個(gè)比較常用：應(yīng)用服務(wù)器蚓土，數(shù)據(jù)庫服務(wù)器以及客戶機(jī)的CPU，內(nèi)存赖淤，硬盤等配置
4蜀漆、數(shù)據(jù)庫瓶頸，以O(shè)RACLE為例咱旱，SYS中默認(rèn)的一些參數(shù)設(shè)置
5确丢、應(yīng)用程序本身瓶頸，
針對網(wǎng)絡(luò)瓶頸吐限，現(xiàn)在冒似很少鲜侥，不過也不是沒有，首先想一下如果有網(wǎng)絡(luò)的阻塞诸典，斷網(wǎng)描函，帶寬被其他資源占用，限速等情況狐粱，應(yīng)用程序或系統(tǒng)會是什么情況舀寓，針對WEB，無非是超時(shí)肌蜻，HTTP400互墓，500之類的錯(cuò)，針對一些客戶端程序蒋搜，可能也是超時(shí)篡撵，掉線，服務(wù)器下發(fā)的豆挽，需要服務(wù)器返回的信息獲取不到還有一種更明顯的情況酸休，應(yīng)該就是事務(wù)提交慢，如果封裝事務(wù)的代碼再不完善祷杈，一般造成的錯(cuò)誤，無非就是數(shù)據(jù)提交不完整渗饮，或者因?yàn)榫W(wǎng)終原因+代碼缺陷造成重復(fù)性提交但汞。如此綜合下來宿刮，肯定是考慮網(wǎng)絡(luò)有瓶頸，然后考慮網(wǎng)絡(luò)有問題時(shí)私蕾，怎樣去優(yōu)化僵缺，是需要優(yōu)化交互的一些代碼，還是接口之類的踩叭。
應(yīng)用服務(wù)的瓶頸的定位磕潮，比較復(fù)雜，學(xué)習(xí)中容贝，不過網(wǎng)上有很多資料可以參考的自脯。一般像tomcat，weblogic之類的斤富，有默認(rèn)的設(shè)置膏潮，也有經(jīng)過架構(gòu)和維護(hù)人員進(jìn)行試驗(yàn)調(diào)試的一些值，這些值一般可以滿足程序發(fā)布的需要满力，不必進(jìn)行太多的設(shè)置焕参，可能我們認(rèn)識的最基本的就是JAVA_OPTS的設(shè)置，maxThreads油额，time_out之類的參數(shù)我們做借助LR叠纷，Jemeter或webload之類的工具，執(zhí)行性能測試潦嘶，尤其是對應(yīng)用服務(wù)造成了壓力涩嚣，如果應(yīng)用服務(wù)有瓶頸，一般我們設(shè)置的log4j.properties衬以，日志都會記錄下來缓艳。然后根據(jù)日志，去進(jìn)一步確定應(yīng)用服務(wù)的問題
系統(tǒng)瓶頸看峻，這個(gè)定位雖說比較復(fù)雜阶淘，但是有很多前輩的經(jīng)驗(yàn)值參考，不作說明互妓，相信用LR的同行溪窒，也可以從性能記數(shù)器中得出一些指標(biāo)值，加上nagios冯勉，cacti澈蚌，可以很明顯的看出系統(tǒng)哪些資源夠用，哪些資源明顯不夠用灼狰。不過宛瞄，一般系統(tǒng)瓶頸的造成，是因?yàn)閼?yīng)用程序本身造成的交胚。關(guān)于這點(diǎn)兒的分析和定位份汗，就需要?dú)w入應(yīng)用程序本身瓶頸分析和定位了盈电。
現(xiàn)在基本所有的東東，都離不開數(shù)據(jù)庫這個(gè)后臺杯活，數(shù)據(jù)庫的瓶頸實(shí)在是不知道是什么概念匆帚，數(shù)據(jù)庫管理員的工作，數(shù)據(jù)庫管理員日常做的工作旁钧，可能就是有瓶頸定位的工作吸重，比如：查詢一下V$sys_event，V$sysstat歪今，v$syssql之類的表嚎幸，比對一下日常正常情況下的監(jiān)控?cái)?shù)據(jù)，看一下有沒有異常等彤委。其他方面鞭铆，我也不是太了解。
應(yīng)用程序瓶頸焦影，這個(gè)是測試過程中最需要去關(guān)注的车遂，需要測試人員和開發(fā)人員配合執(zhí)行，然后定位斯辰，我這兒做的大都是執(zhí)行性的舶担，比如會有腳本去運(yùn)行，開發(fā)人員會結(jié)合jprofiler之類的工具彬呻，去看一下堆遍歷衣陶，線程剖析的情況確定哪兒有問題。大致是這樣闸氮，沒有實(shí)際操作過
逐步細(xì)化分析剪况，先可以監(jiān)控一些常見衡量CPU，內(nèi)存蒲跨，磁盤的性能指標(biāo)译断，進(jìn)行綜合分析，然后根據(jù)所測系統(tǒng)具體情況或悲，進(jìn)行初步問題定位孙咪，然后確定更詳細(xì)的監(jiān)控指標(biāo)來分析。
方法1：
【監(jiān)控指標(biāo)】：Memory Available MBytes 巡语，Memory的Pages/sec翎蹈， page read/sec， Page Faults/sec
【參考值】：
如果 Page Reads/Sec 比率持續(xù)保持為 5男公，表示可能內(nèi)存不足荤堪。
Page/sec 推薦00-20（如果服務(wù)器沒有足夠的內(nèi)存處理其工作負(fù)荷，此數(shù)值將一直很高。如果大于80逞力，表示有問題）曙寡。
方法2：根據(jù)Physical Disk 值分析性能瓶頸
【監(jiān)控指標(biāo)】：Memory Available MBytes ，Pages read/sec寇荧，%Disk Time 和 Avg.Disk Queue Length
【參考值】：%Disk Time建議閾值90%
當(dāng)內(nèi)存不足時(shí)，有點(diǎn)進(jìn)程會轉(zhuǎn)移到硬盤上去運(yùn)行执隧，造成性能急劇下降揩抡，而且一個(gè)缺少內(nèi)存的系統(tǒng)常常表現(xiàn)出很高的CPU利用率，因?yàn)樗枰粩嗟膾呙鑳?nèi)存镀琉，將內(nèi)存中的頁面移到硬盤上峦嗤。
【監(jiān)控指標(biāo)】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set屋摔，PhysicalDisk/%Disk Time
【說明】：
Windows資源監(jiān)控中烁设，如果Process\Private
Bytes計(jì)數(shù)器和Process\Working Set計(jì)數(shù)器的值在長時(shí)間內(nèi)持續(xù)升高，同時(shí)Memory\Available
bytes計(jì)數(shù)器的值持續(xù)降低钓试，則很可能存在內(nèi)存泄漏装黑。內(nèi)存泄漏應(yīng)該通過一個(gè)長時(shí)間的，用來研究分析當(dāng)所有內(nèi)存都耗盡時(shí)弓熏，應(yīng)用程序反應(yīng)情況的測試來檢驗(yàn)恋谭。
CPU分析
【監(jiān)控指標(biāo)】：
System %Processor Time CPU，Processor %Processor Time CPU
Processor%user time 和Processor%Privileged Time
system\Processor Queue Length
Context Switches/sec 和%Privileged Time
【參考值】：
System\%Total processor time不持續(xù)超過90%挽鞠，如果服務(wù)器專用于SQL Server疚颊，可接受的最大上限是80-85% ，合理使用的范圍在60%至70%信认。
Processor %Processor Time小于75%
system\Processor Queue Length值材义，小于CPU數(shù)量的總數(shù)+1
1、System\%Total processor time如果該值持續(xù)超過90%嫁赏，且伴隨處理器阻塞其掂，則說明整個(gè)系統(tǒng)面臨著處理器方面的瓶頸.
注：在某些多CPU系統(tǒng)中，該數(shù)據(jù)雖然本身并不大橄教，但CPU之間的負(fù)載狀況極不均衡清寇，此時(shí)也應(yīng)該視作系統(tǒng)產(chǎn)生了處理器方面的瓶頸.
2、排除內(nèi)存因素护蝶，如果Processor
%Processor Time計(jì)數(shù)器的值比較大华烟，而同時(shí)網(wǎng)卡和硬盤的值比較低，那么可以確定CPU
瓶頸持灰。（內(nèi)存不足時(shí)盔夜，有點(diǎn)進(jìn)程會轉(zhuǎn)移到硬盤上去運(yùn)行，造成性能急劇下降，而且一個(gè)缺少內(nèi)存的系統(tǒng)常常表現(xiàn)出很高的CPU利用率喂链，因?yàn)樗枰粩嗟膾呙鑳?nèi)存返十，將內(nèi)存中的頁面移到硬盤上。）
造成高CPU使用率的原因：
頻繁執(zhí)行程序椭微，復(fù)雜運(yùn)算操作洞坑，消耗CPU嚴(yán)重
數(shù)據(jù)庫查詢語句復(fù)雜，大量的 where 子句蝇率，order by迟杂， group by 排序等，CPU容易出現(xiàn)瓶頸
內(nèi)存不足本慕，IO磁盤問題使得CPU的開銷增加
磁盤I/O分析
【監(jiān)控指標(biāo)】：PhysicalDisk/%Disk time排拷，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length锅尘， Disk sec/Transfer
【參考值】：%Disk Time建議閾值90%
Windows資源監(jiān)控中监氢，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低藤违，則可能存在磁盤瓶徑浪腐。
Processor%Privileged
Time該參數(shù)值一直很高，且如果在 Physical Disk 計(jì)數(shù)器中纺弊，只有%Disk time
比較大牛欢，其他值都比較適中，硬盤可能會是瓶頸淆游。若幾個(gè)值都比較大傍睹， 那么硬盤不是瓶頸。若數(shù)值持續(xù)超過80%犹菱，則可能是內(nèi)存泄露拾稳。如果 Physical
Disk 計(jì)數(shù)器的值很高時(shí)該計(jì)數(shù)器的值（Processor%Privileged Time）也一直很高，
則考慮使用速度更快或效率更高的磁盤子系統(tǒng)腊脱。
Disk sec/Transfer 一般來說访得，該數(shù)值小于15ms為最好，介于15-30ms之間為良好陕凹，30-60ms之間為可以接受悍抑，超過60ms則需要考慮更換硬盤或是硬盤的RAID方式了.
Average Transaciton Response Time（事務(wù)平均響應(yīng)時(shí)間）隨著測試時(shí)間的變化，系統(tǒng)處理事務(wù)的速度開始逐漸變慢杜耙，這說明應(yīng)用系統(tǒng)隨著投產(chǎn)時(shí)間的變化搜骡，整體性能將會有下降的趨勢
Transactions per Second（每秒通過事務(wù)數(shù)/TPS）當(dāng)壓力加大時(shí)，點(diǎn)擊率/TPS曲線如果變化緩慢或者有平坦的趨勢佑女，很有可能是服務(wù)器開始出現(xiàn)瓶頸
Hits per Second（每秒點(diǎn)擊次數(shù)）通過對查看“每秒點(diǎn)擊次數(shù)”记靡，可以判斷系統(tǒng)是否穩(wěn)定谈竿。系統(tǒng)點(diǎn)擊率下降通常表明服務(wù)器的響應(yīng)速度在變慢，需進(jìn)一步分析摸吠，發(fā)現(xiàn)系統(tǒng)瓶頸所在空凸。
Throughput（吞吐率）可以依據(jù)服務(wù)器的吞吐量來評估虛擬用戶產(chǎn)生的負(fù)載量，以及看出服務(wù)器在流量方面的處理能力以及是否存在瓶頸寸痢。
Connections（連接數(shù)）當(dāng)連接數(shù)到達(dá)穩(wěn)定狀態(tài)而事務(wù)響應(yīng)時(shí)間迅速增大時(shí)呀洲，添加連接可以使性能得到極大提高（事務(wù)響應(yīng)時(shí)間將降低）
Time to First Buffer Breakdown（Over Time）（第一次緩沖時(shí)間細(xì)分（隨時(shí)間變化））可以使用該圖確定場景或會話步驟運(yùn)行期間服務(wù)器或網(wǎng)絡(luò)出現(xiàn)問題的時(shí)間。
1. 在高并發(fā)的情況下轿腺，產(chǎn)生的處理失斄阶臁（比如：數(shù)據(jù)庫連接池過低，服務(wù)器連接數(shù)超過上限族壳，數(shù)據(jù)庫鎖控制考慮不足等）
2. 內(nèi)存泄露（比如：在長時(shí)間運(yùn)行下，內(nèi)存沒有正常釋放趣些，發(fā)生宕機(jī)等）
3. CPU使用偏離（比如：高并發(fā)導(dǎo)致CPU使用率過高）
4. 日志打印過多仿荆，服務(wù)器無硬盤空間
1. 查看系統(tǒng)日志，日志是定位問題的不二法寶坏平，如果日志記錄的全面拢操，很容易通過日志發(fā)現(xiàn)問題。
比如舶替，系統(tǒng)宕機(jī)時(shí)令境，系統(tǒng)日志打印了某方法執(zhí)行時(shí)拋出out of memory的錯(cuò)誤，我們就可以順藤摸瓜顾瞪，很快定位到導(dǎo)致內(nèi)存溢出的問題在哪里舔庶。
2. 利用性能監(jiān)控工具，比如：JAVA開發(fā)B/S結(jié)構(gòu)的項(xiàng)目陈醒，可以通過JDK自帶的Jconsole惕橙，或者JProfiler，來監(jiān)控服務(wù)器性能钉跷，Jconsole可以遠(yuǎn)程監(jiān)控服務(wù)器的CPU弥鹦，內(nèi)存，線程等狀態(tài)爷辙，并繪制變化曲線圖彬坏。
利用Spotlight可以監(jiān)控?cái)?shù)據(jù)庫使用情況。
我們需要關(guān)注的性能點(diǎn)有：CPU負(fù)載膝晾，內(nèi)存使用率栓始，網(wǎng)絡(luò)I/O等
3. 工具和日志只是手段，除此之外玷犹，還需要設(shè)計(jì)合理的性能測試場景
具體場景有：性能測試混滔，負(fù)載測試洒疚，壓力測試，穩(wěn)定性測試坯屿，浪涌測試等
好的測試場景油湖，能更加快速的發(fā)現(xiàn)瓶頸，定位瓶頸
4. 了解系統(tǒng)參數(shù)配置领跛，可以進(jìn)行后期的性能調(diào)優(yōu)
除此以外乏德，還想說個(gè)題外話，就是關(guān)于性能測試工具的使用問題
在剛開始用Loadrunner和JMeter的時(shí)候吠昭，做高并發(fā)測試時(shí)喊括，都出現(xiàn)過沒有把服務(wù)器壓垮，這兩個(gè)程序自己先倒下的情況矢棚。
如果遇到這個(gè)問題郑什，可以通過遠(yuǎn)程調(diào)用多個(gè)客戶端的服務(wù)，分散性能測試工具客戶端的壓力來解決蒲肋。
說這個(gè)的目的是想說蘑拯，做性能測試的時(shí)候，我們一定要確保瓶頸不要發(fā)生在我們自己的測試腳本和測試工具上兜粘。
原網(wǎng)址：http://www.doc88.com/p-0088541351664.html
