跟著芒果一起好好學習,，天天向上~

上周六是我們TestOps性能進階課程第八天——性能測試實戰(zhàn)的學習,。這一天的課程是由測試行業(yè)的大牛葉微微老師為我們帶來的,，必須是干貨滿滿。老師教大家一起學習企業(yè)級的性能測試應(yīng)該如何做,，這里芒果一如既往的抽出其中一部分內(nèi)容跟大家介紹~

需求點的選取

首先芒果要介紹的是需求點的選取,。

需求點的選取第一個要做到的就是明確需求：要了解本次性能測試的背景以及當前項目的現(xiàn)狀；要此次清楚性能測試的目的,；要根據(jù)業(yè)務(wù)的緊急程度,，系統(tǒng)是第一次上線還是迭代升級，服務(wù)隊性能的要求等情況,，來選擇是上線前進行性能測試還是上線后,。

第二個要做的是明確壓測范圍：到底是對頁面進行壓力測試，還是接口進行,，或者是對場景的壓測,；明確是對哪些頁面、接口或者是場景進行測試,。

第三個也是最重要的一點就是熟悉被測業(yè)務(wù)：要熟悉被測的模塊,，要熟悉被測系統(tǒng)的系統(tǒng)架構(gòu)、業(yè)務(wù)形態(tài),，要了解系統(tǒng)的緩存機制,、消息隊列；要知道被測的業(yè)務(wù)有什么特點,，到底是cpu密集型還是io密集型,；對于接口的性能，要對接口邏輯,、數(shù)據(jù)流,、接口服務(wù)依賴,、基礎(chǔ)依賴的流程進行詳細了解。

性能測試的指標

第二個要給大家介紹的是性能測試的指標,。一般來說企業(yè)級系統(tǒng)的性能指標一般從吞吐量（每秒系統(tǒng)能夠處理的請求數(shù),、任務(wù)數(shù)）、響應(yīng)時間（服務(wù)處理一個請求或者任務(wù)的時間）,、錯誤率（一批請求中結(jié)果出錯的請求所占的比例）,、資源消耗（服務(wù)處理請求消耗的資源，如CPU,、內(nèi)存,、IO等）來考慮。

在這里葉老師給大家展示了,，他所在企業(yè)的某個測試項目的性能測試指標：

葉老師還給大家介紹了常用的QPS（單個進程每秒請求服務(wù)器的成功次數(shù)）,、PV（page view，即頁面流覽量）和需要部署機器數(shù)量計算公式,。

術(shù)語說明：

QPS = req/sec = 請求數(shù)/秒

QPS計算PV和機器的方式：

QPS統(tǒng)計方式 [一般使用 http_load 進行統(tǒng)計]

QPS = 總請求數(shù) / ( 進程總數(shù) *請求時間 )

單臺服務(wù)器每天PV計算：

公式1：每天總PV = QPS * 3600 * 6

公式2：每天總PV = QPS * 3600 * 8

峰值QPS和機器計算公式：

原理：每天80%的訪問集中在20%的時間里,，這20%時間叫做峰值時間（雖然有些時候二八原則不是很準確，但是在葉老師這次舉例的項目二八原則是符合要求的）

公式：( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時間每秒請求數(shù)(QPS)

機器：峰值時間每秒QPS / 單臺機器的QPS   = 需要的機器

簡單舉例

問：每天600w PV 的在單臺機器上,，這臺機器需要多少QPS,？

答：( 6000000 * 0.8 ) / (86400 * 0.2 ) = 278 (QPS)

問：如果一臺機器的QPS是100,，需要幾臺機器來支持,？

答：278 / 100 約等于  3

性能測試案例

然后葉老師還給大家展示了這個項目的部分性能測試案例，并對這些案例進行了詳細分析,。在介紹的過程中葉老師提到對于內(nèi)部服務(wù)接口,，頁面請求接口可以通過一些測試工具或者抓包工具去獲取到，也可以通過跟開發(fā)溝通來拿到這些接口,，然后根據(jù)具體業(yè)務(wù)來確定是哪些,。對于接口性能測試，一般情況下接口會特別多,，所以不會都測,，主要是有可能出問題跟核心接口，要分優(yōu)先級,，其余的可以使用自動化接口,，或者使用測試平臺進行測試。以下是部分測試案例的截圖,，以供大家參考：

監(jiān)控工具nmon

這次的實戰(zhàn)項目的測試執(zhí)行是使用Jmeter進行的,，由于之前我們有對Jmeter進行深入的學習，芒果在這里就不過多的介紹,。介紹一下葉老師在項目中使用的監(jiān)控工具nmon：

Nmon可以對被測系統(tǒng)的CPU占用率,、內(nèi)存使用情況,、磁盤IO、網(wǎng)絡(luò)IO,、文件系統(tǒng)使用率,、進程消耗進行監(jiān)控。分別輸入 c,、t,、n、m,，可以了解系統(tǒng) CPU,，Memory，消耗資源最高的線程的使用情況：

如果想要實時監(jiān)控系統(tǒng)在一段時間內(nèi)的使用情況并將結(jié)果記錄下來,，我們可以通過運行以下命令實現(xiàn):

#./ nmon -f -t -r test -s 30 -c 180
l test:這次監(jiān)控記錄的標題,，與生產(chǎn)的文件名稱
l -s 30:每30秒進行一次數(shù)據(jù)采集
l -c 180:一共采集180次
以上就是 nmon 記錄了系統(tǒng)在 1.5 小時內(nèi)的使用情況輸入命令后，將自動在當前目錄生成一個hostname_timeSeries.nmon 的文件（hostname為當前服務(wù)器的主機名,，如:hosname為dell,，生產(chǎn)的文件為:dell_090320_2213.nmon）。

可以通過以下命令將 nmon 結(jié)果轉(zhuǎn)換為 csv 文件:
# sort -A dell_090320_2213.nmon > dell_090320_2213.csv
即可在當前目錄生成 test1_090320_2213.csv 文件,。我們將 dell_090320_2213.csv 文件下載本地,，通過 nmon_analyser 工具轉(zhuǎn)換為 excel 文件，此時打開 excel 文件,，我們即可通過圖形化方式查看到系統(tǒng)的運行趨勢圖了,。

常見問題處理

接著芒果要給大家介紹的是葉老師傳授給大家的，對于性能測試過程中一些常見問題的處理方式：

1,、服務(wù)器,、壓力機資源都沒問題的情況下，壓力上不去是什么原因造成的,？

    1）用另一個接口進行壓測,，看壓力是否沒問題，來排除是程序還是環(huán)境問題,； 

    2）如果是環(huán)境問題,，因環(huán)境都是虛擬機，換個壓力機或服務(wù)器,，看下是否正常,； 

    3）查看中間件等配置參數(shù)，確保中間件的配置無誤,；  

    4）通過工具查看網(wǎng)絡(luò)是否有問題,；  

    5）如果是程序問題，查看log,，打印出每個節(jié)點的響應(yīng)時間,，看具體響應(yīng)時間長在哪,。                   

2、出現(xiàn)問題,，如何排查是否是代碼還是數(shù)據(jù)庫問題,？

    打印出詳細的log可以看出。

3,、設(shè)置場景時,，怎樣設(shè)置思考時間或pacing更合理？

分場景來定,，如果需要測拐點,，可以不用設(shè)置，如果需要模擬真實場景,，則需要設(shè)置,；  思考時間是每個腳本中間設(shè)置的，pacing的話,，則是在一個迭代結(jié)束后,，等待pacing設(shè)置的時間后，再開始另一個迭代,。

4,、如何測試dubbo接口？

    loadrunner測的時候,，將dubbo外封裝一層http的包,，用http協(xié)議測試  jmeter測的時候，將dubbo接口配置,，寫一個java腳本,，打包成jar包,，放在jmeter的lib的ext目錄下,，用java協(xié)議測試。  

5,、什么場景下會用到集合點,？

    一般不建議用集合點，除非是秒殺等相關(guān)場景下才會用到集合點,。

6,、同一腳本，場景配置全都一樣,，可結(jié)果不同,，有哪些原因？

    一般情況下,，都不會一模一樣,，差不太多的話也算是正常  但是如果差距很大,，就需要排查問題了，可能原因有：cpu,、內(nèi)存,、io等相關(guān)資源，redis緩存,，網(wǎng)絡(luò)等,。  

7、在無指標的情況下,，如何判斷該條用例是否通過,？

    1）響應(yīng)時間，看是接口還有頁面,，接口的話基本在幾十毫秒到幾百毫秒之間,，如果時間太長，還是需要進行優(yōu)化的,，如果是頁面,，基本遵循二五八原則；  

    2）用戶數(shù)基本分是單服務(wù)還是集群來分開測,，單服務(wù)50～200用戶,，集群基本300～500用戶；

3）服務(wù)器資源,，一般不建議超過80%,，因為如果一臺服務(wù)掛了，另外的服務(wù)器可以接收這臺服務(wù)器的所有請求,；  

    4）成功率,，一般成功率支持99.99%  如果以上都沒問題，那可判斷該用例通過,，否則失敗,，需排查原因及調(diào)優(yōu)。

8,、tps或響應(yīng)時間偶爾出現(xiàn)一個大的抖動,，如何排查具體原因？

    監(jiān)控當時的網(wǎng)絡(luò)及服務(wù)器,、壓力機等資源,，是否因為環(huán)境造成。

9,、tps或響應(yīng)時間出現(xiàn)很規(guī)律的上下抖動,，如何排查具體原因？

    之前測試https的時候遇到過,，上下抖動很規(guī)律,，當時主要原因是lvs的問題,，逐個在外網(wǎng)、lvs測試相同場景,，可查出,，后來運維優(yōu)化lvs后，問題解決,。

10,、查詢單個商品接口沒問題，但改成多個商品后,，壓力上不去,，如何優(yōu)化？

    當時測試批量查詢價格接口時,，壓力上不去,，了解程序是同時獲取24個商品查詢價格返回，如果緩存中僅有幾個商品沒有,，也還是會去庫里獲取全部數(shù)據(jù)更新到緩存內(nèi)再返回,，后優(yōu)化成：先mget到所有數(shù)據(jù)，如果查詢到部分是空的,，則再去數(shù)據(jù)庫獲取部分數(shù)據(jù),，將獲取到的數(shù)據(jù)更新到緩存內(nèi)再返回。

性能測試小訣竅

最后芒果要給大家介紹的是葉老師在做項目的過程中介紹的一些小訣竅：

日志相關(guān)：去除無用日志（整體優(yōu)化,，提升IO性能）,，去除debug級別日志，去除重復的日志輸出,。

數(shù)據(jù)庫相關(guān)：增加數(shù)據(jù)庫連接數(shù)（提升DB處理性能,，改善接口性能）依據(jù)慢SQL（DAO操作耗時可查看**time-handler**.log）以及業(yè)務(wù)場景，增加索引/重建索引（提升DB處理性能）,，索引優(yōu)化（組合索引優(yōu)于多個單索引）,。

代碼相關(guān)：通過日志文件，找出耗時較長的功能代碼塊,，進行業(yè)務(wù)代碼優(yōu)化（整體優(yōu)化）,，去除無用代碼。

接口相關(guān)：增加dubbo線程池大?。J200）及客戶端調(diào)用方法的超時時間（客戶端與服務(wù)端超時時間相匹配），提升duboo接口性能（提升臺賬和促銷接口性能）增加項目部署節(jié)點（響應(yīng)時間正常但CPU過高）CUP負載不均勻,。

Nginx相關(guān)：調(diào)整nginx負載策略磁盤空間不夠影響處理性能,，降低TPS，及時清理日志文件（不要rm 或者 mv,，執(zhí)行 echo "" > xxx.log）,。

JVM相關(guān)：分析進程堆棧信息（CUP使用率過高時可分析部分原因）  

 ./usr/local/java/jdk1.7.0_80/bin/jstack -l pid |sort | uniq -c |sort

當然這一天的學習內(nèi)容肯定不只芒果介紹的這么一些,，葉老師在帶著同學們做項目實戰(zhàn)的過程中，給大家介紹了在企業(yè)中如何進行需求分析,，如何制定測試方案,，帶大家寫了一些接口性能測試腳本，并執(zhí)行這些測試腳本,，生成并分析了測試結(jié)果,，詳細介紹了nmon監(jiān)控的使用。幫助一些學員解決他們在工作中進行性能測試的一些問題也是葉老師帶給同學們的特別福利喲~

要想學習各種不一樣的知識,，掌握課程的精髓,，跟老師們一起互動，一起解決問題,，還是要參與到我們的課程中來喲~

文章最后曬一下wuli貼心的葉老師：

點擊原文可以到達我們的課程學習頁面喲~