性能測試和性能分析的基礎概念

1.1.   性能測試的基礎概念

性能能夠理解爲一個系統實現其功能的能力，從宏觀上能夠描述爲系統可以穩定運行，高併發訪問時系統不會出現宕機，系統處理完成用戶請求須要的時間，系統可以同時支撐的併發訪問量，系統每秒能夠處理完成的事物數等，從微觀上能夠描述爲處理每一個事務的資源開銷，資源的開銷能夠包括CPU，磁盤IO，內存，網絡傳輸帶寬等，甚至能夠體現爲服務器連接數，線程數，JVM Heap等的使用狀況，也能夠表現爲內存的分配回收是否及時，緩存規則的命中率等。

性能到底有多重要呢，咱們能夠舉一個網站訪問的例子來講明，一個網頁的加載速度若是超過4-5秒，可能25%的人會選擇放棄。百度的搜索結果響應時間慢0.4秒，一天的搜索量可能會減小千萬左右。因此一個系統，一個網站的性能決定了其可以支撐業務的能力。

不一樣的羣體對性能的理解可能會存在很大的差別，普通的用戶更加關心響應時間和穩定性。

l         訪問頁面響應還要讓我等多久才能加載出來？

l         爲何有時候會訪問失敗？爲何會出現502？

架構師和工程師可能更加關心架構設計和代碼編寫的性能

l         應用架構設計是否合理？

l         技術架構設計是否合理？

l         數據架構設計是否合理？

l         部署架構設計是否合理？

l         代碼是否存在性能問題？

l         JVM中是否有不合理的內存分配和使用？

l         線程同步和線程鎖是否合理？

l         代碼的計算算法是否能夠進一步優化以減小CPU的消耗時間？

運維工程師可能更加關心繫統的監控以及穩定性狀況

l         服務器各項資源使用率在正常範圍內嗎？

l         數據庫的連接數在正常範圍內嗎？

l         Sql執行時間正常嗎，是否存在慢查詢日誌？

l         系統可以支撐7*24小時連續不間斷的業務訪問嗎？

l         系統是高可用的嗎，服務器節點宕機了會影響用戶使用嗎？

l         對節點擴容後，能夠提升系統的性能嗎？

l          

1.1.1         性能測試的分類

性能測試的類型一般包括以下幾種：

l         性能測試：尋求系統在正常負載下的各項性能指標， 或者經過調整併發用戶數，使系統資源的利用率處於正常水平時獲取到系統的各項性能指標。

l         負載測試：系統在不一樣負載下的性能表現，經過該項測試能夠尋求到系統在不一樣負載下的性能變化曲線，從而尋求到性能的拐點。例如負載測試時，在只不斷遞增併發用戶數時，觀察各項性能指標的變化規律，找到系統能到達的最大TPS，而且觀察此時系統處理的平均響應時間和各項系統資源和硬件資源的消耗狀況。

l         壓力測試：系統在高負載下的性能表現，該項測試主要爲了尋求系統可以承受的最大負載以及此時系統的吞吐率，經過該測試也能夠發現系統在超高負載下是否會出現崩潰沒法訪問以及在系統負載減少後，系統性能可否自動恢復。

l         基準測試：針對待測系統進行版本執行的測試，採集各項性能指標做爲後期版本性能的對比。

l         穩定性測試：以正常負載或者略高於正常負載來對系統進行長時間的測試，檢測系統是否能夠長久穩定運行以及系統的各項性能指標會不會隨着時間發生明顯變化。

l         擴展性測試：一般用於新上線的系統或者新搭建的系統環境，經過先測試單臺服務器的處理能力，而後慢慢增長服務器的數量，測試集羣環境下單臺服務器的處理能力是否有損耗，集羣環境的性能處理能力是否能夠呈現穩定增長。

1.1.2        性能測試的場景

 性能測試的場景類型一般包含以下幾種：

l         業務場景：一般指的是系統的業務處理流程，描述具體的用戶行爲，經過對用戶行爲進行分析劃分出不一樣的業務場景，是性能測試時測試場景設計的重要來源。

l         測試場景：測試場景是對業務場景的真實模擬，測試場景的設計應該儘量貼近真實的業務場景，有時候因爲測試條件的限制，能夠適當作一些調整和特殊的設置等。

l         單場景：指的是隻涉及單個業務流程的測試場景，目的是測試系統的單個業務處理能力是否達到預期，而且獲得系統資源利用正常狀況下的最大TPS，平均響應時間等性能指標。

l         混合場景：測試場景中涉及到多個業務流程，而且每一個業務流程在混合的業務流程中佔的比重會不一樣，該比重通常根據實際的業務流程來設定，儘量符合實際的業務須要，該測試場景的目的是爲了測試系統的混合業務處理能力是否知足預期要求。而且評估到系統的混合業務處理容量最大能達到多少。

1.2.   常見的性能測試指標

衡量一個系統性能的好壞，在性能測試中會使用一些性能指標來進行分析和描述，如下是一些最經常使用的性能指標。

1.2.1        響應時間

  請求或者某個操做從發出的時間到收到服務器響應的時間的差值，在性能測試中，通常統計的是事物的響應時間。

下圖是一次標準http請求可能通過的處理路徑和節點，那麼響應的時間的計算方式就是全部路徑消耗的時間和每一個服務器節點處理時間的累加，一般是網絡時間+應用程序的處理時間。

 

1.2.1        TPS/QPS

事務：自定義的某個操做或者一組操做的集合，例如在一個系統的登陸頁面，輸入用戶名和密碼，從點擊登陸按鈕開始到登陸完成跳轉到頁面而且新的頁面徹底加載完成，這一個操做咱們就能夠定義爲一個事務。

TPS是Transaction Per Second的縮寫，即系統每秒可以處理的交易和事物的數量，通常統計的是每秒經過的事物數。

QPS是每秒查詢率(Query Per Second) 的縮寫，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。

1.2.2        併發用戶

在真實的用戶操做中，用戶的每一個相鄰操做之間都會有必定的間隔時間（在性能測試中，咱們稱爲用戶思考時間），因此併發用戶通常有絕對併發和相對併發之分，絕對併發是指某個時間點同時一塊兒向服務器發出請求的併發用戶數，相對併發是指一段時間內向服務器發出請求的併發用戶總數。單就性能指標而言，系統的併發用戶數是指系統能夠同時承載的正常使用系統功能的用戶的總數量。

針對併發用戶咱們舉例說明，在京東購物網站上購買一件商品的流程包括登陸，瀏覽商品，把商品加入購物車，去購物車結算，確認商品清單，確認收貨地址信息，最後提交訂單去支付。若是200人同時按照這個流程在購買一件商品，但由於每一個人購買商品的步驟有快有慢，因此在同一時間點向服務器發出請求的用戶是確定不會有200個的，會遠遠小於200個，咱們假設爲20，那麼上面說的200個用戶就是相對併發用戶數，而20就是絕對的併發用戶數。

1.2.3        PV/UV

l         PV：Page View的簡寫，即頁面的瀏覽量或者點擊量，用戶每次對系統或者網站中任何頁面的訪問均會被記錄一次，用戶若是對同一頁面進行多方訪問，那麼訪問量會進行累加。PV通常是衡量電子商務網站性能容量的重要指標，PV的統計能夠分爲全天PV，每一個小時的PV以及峯值PV（高峯1小時的PV）。

l         UV：Unique Visitor的簡寫，即指系統的獨立訪客，訪問系統網站的一臺電腦客戶端會稱爲一個訪客，天天00:00點到第二天00:00點內相同的客戶端只能被計算一次，一樣UV的統計也能夠分爲全天UV，每一個小時的UV以及峯值UV（高峯1小時的UV）。

PV和UV一般是衡量Web網站的兩個很是重要的指標，PV/s通常是由TPS經過必定的模型轉化爲PV，好比若是把每個完整的頁面都定義爲一個事務，那麼TPS就能夠等同於PV/s。PV和UV之間通常存在一個比例，PV/UV能夠理解爲每一個用戶平均瀏覽訪問的頁面數，這個比值在不一樣的時間點會所波動，好比雙11電商大促時PV/UV的比重會比平時高不少。

1.2.4        點擊率

每秒的Hit點擊數咱們稱之爲點擊率，該性能指標反映了客戶端每秒向服務端提交的請求數，一般一個hit對應了一次http請求，在性能測試中，咱們通常不發起靜態請求（指的是對靜態資源的請求，好比js，css圖片文件等），因此hit一般是指的動態請求。在性能測試中，咱們之因此不發起靜態請求是由於靜態請求通常是能夠走緩存，好比CDN等，不少靜態請求通常都不須要通過應用服務器的處理，要麼直接走CDN緩存，要麼直接請求到Web服務器就被處理完成了。

1.2.5        吞吐量

吞吐量是指系統在單位時間內處理客戶端請求的數量，不一樣的角度，吞吐量的計算方式能夠不同。

l         從業務角度：吞吐量能夠用請求數/s，頁面數/s等來進行衡量計算。

l         從網絡角度：吞吐量能夠用字節/s來進行衡量計算。

l         從應用角度：吞吐量指標反映的是服務器承受的壓力即系統的負載能力

一個系統的吞吐量通常與一個請求處理對CPU的消耗、帶寬的消耗、IO和內存資源的消耗狀況等緊密相連。

1.2.6        資源開銷

每一個請求或者事務對系統資源的消耗，用來衡量請求或者事務對資源的消耗程度，例如對CPU的消耗能夠用佔用CPU的秒數或者核數來衡量，對內存的消耗能夠用內存使用率來衡量，對IO的消耗能夠用每秒讀寫磁盤的字節數來衡量。在性能測試中，資源的開銷是一個能夠量化的概念，資源的開銷狀況對性能指標有着重要的影響，咱們通常作性能優化時，都是儘量讓每個請求或者事務對系統資源的消耗減小到最小。

1.3.   性能測試的基本流程

一般狀況下，性能測試通常會經歷以下階段，這些階段能夠和不少性能測試工具對應起來，好比分析性能測試結果能夠用Loadrunner的ANALYSIS工具來實現。

 

1.3.1   性能需求分析

l         熟悉被壓測系統的基本業務流程，明確這次性能測試要達到的目標，與產品經理、業務人員、架構師、技術經理一塊兒溝通，找到業務需求的性能點。

l         熟悉系統的應用架構、技術架構、數據架構、部署架構等，找到與其餘系統的交互流程，明確系統部署的硬件配置信息，軟件配置信息，把對性能測試有重要影響的關鍵點須要明確的列舉出來，通常包括以下：

²        用戶發起請求的順序、請求之間的相互調用關係。

²        業務數據流走向、數據是如何流轉的、通過了哪些應用服務、通過了哪些存儲服務

²        評估被壓測系統可能存在的重點資源消耗，是IO消耗型、CPU消耗型仍是內存消耗型，這樣在壓測執行時能夠重點進行監控。

²        關注應用的部署架構，若是是集羣部署，壓測時須要關注應用的負載均衡轉發是否均勻，每臺應用服務器資源消耗是否大致一致。

²        和技術經理一塊兒溝通，明確應用的併發架構，是採用多線程處理仍是多進程處理，重點須要關注是否會死鎖、數據不一致，線程同步鎖是否合理（鎖的粒度通常不宜過大，過大時可能會影響併發線程的處理）等。

l         明確系統上線後可能會達到的最大併發用戶數，用戶指望的平均響應時間以及峯值時的業務吞吐量，將這些信息轉化爲性能需求指標。

1.3.2   制定性能測試計劃

性能測試計劃是性能測試的指導，是一系列測試活動的依據，在制定性能測試計劃時須要明確系統的上線時間點、當前項目的進度以及所處的階段、能夠供調配的硬件資源和性能測試人員。一個完整的性能測試計劃通常包括以下幾個部分：

l         性能測試計劃編寫的目的：主要是做爲整個性能測試過程的指導，讓性能測試環境搭建、測試策略的選取、任務與進度事項跟蹤、性能測試風險分析等事項有序的進行，同時也須要明確這次性能測試預期須要達到的標準以及性能測試完成退出測試的條件。

l         明確各個階段的具體執行時間點以及對應的責任人：

• 預計由誰什麼時候開始性能需求分析，什麼時候結束性能需求分析
• 預計由誰什麼時候完成性能測試方案的編寫，什麼時候結束性能測試方案的編寫
• 預計由誰什麼時候完成性能測試案例的編寫，什麼時候結束性能測試案例的編寫
• 預計由誰什麼時候開始搭建性能測試環境，什麼時候結束性能測試環境的搭建
• 預計由誰什麼時候開始準備性能測試須要的數據，什麼時候準備完畢
• 預計由誰什麼時候開始編寫性能測試腳本，什麼時候編寫完畢，性能測試腳本的編寫通常包含以下步驟：

²        按照性能測試場景，開始錄製性能測試腳本或者直接編寫性能測試腳本，此時可能用到的常見性能測試工具包括Loadrunner、BadBoy、Jmeter、nGrinder等。

²        根據準備好的測試數據，對性能測試腳本進行參數化，添加集合點，事務分析點等。

²        對性能腳本進行試運行調試，確保不出現報錯，而且能夠覆蓋到測試場景中全部操做。

• 預計由誰什麼時候開始性能測試的執行，什麼時候完成性能測試的執行，此階段通常須要完成以下事項：

²        完成每個性能測試場景和案例的執行，記錄相關的性能測試結果，明確性能曲線的變化趨勢，獲取性能的拐點等。

²        根據性能測試的結果，評估性能數據是否能夠知足預期，從性能測試結果數據中分析存在的性能問題。

²        針對性能問題，進行性能定位和優化，而後進行二次壓測，直至性能數據能夠知足預期，性能測試問題獲得解決。

²        完成性能測試分析報告的編寫。

• 性能測試風險的分析和控制：評估可能存在的風險和不可控的因素以及這些風險和因素對性能測試可能產生的影響，針對這些風險因素須要給出對應的短時間和長期的解決方案。性能測試風險通常包括以下：

²        性能測試環境因素：沒法預期完成性能測試環境的搭建，這中間的緣由多是硬件引發也多是軟件引發，硬件緣由通常可能包括性能壓測服務器沒法按時到位、服務器硬件配置沒法知足預期（通常要求性能壓測服務器硬件配置等同於生產環境，服務器的節點數能夠少於生產環境，可是須要保證每一個應用服務至少部署了兩臺節點服務器）。軟件緣由可能包括性能測試環境軟件配置沒法和生產環境保持一致（通常要求性能壓測環境軟件配置，好比軟件版本、數據庫版本、驅動版本等要和生產環境徹底保持一致）。

²        性能測試人員因素：性能測試人員沒法按時到位參與項目的性能測試，若是出現這樣的風險，確定會致使性能測試沒法預期進行，須要當即向項目經理進行彙報，以確保能夠協調到合適的人員，由於這是一個很是嚴重的風險。

²        性能測試結果沒法達到預期：即系統的性能沒法達到生產預期上線要求或者存在性能問題沒法解決，性能調優其實自己就是一個長期不斷優化的過程，此時能夠看是否經過服務器的橫向或者縱向擴容來解決，若是仍是沒法解決，那麼也須要提早上報風險。

1.3.3   編寫性能測試方案

在有了性能測試計劃後，咱們就須要按照性能需求分析的結果來制定性能測試方案，即按照什麼樣的思路和策略去測試、須要設計哪些測試場景以及測試場景執行的前後順序、每一個測試場景須要重點關注的性能點等，通常包括以下：

• 測試場景的設計

²        單場景設計

²        混合場景設計

• 定義事務：測試方案中須要明肯定義好壓測事務，方便分析響應時間（特別是在混合場景中，事務的定義能夠方便分析每個場景響應時間的消耗）。好比咱們對淘寶網購買商品這一場景進行壓測，能夠把下訂單定義爲一個事務，把支付也定義爲一個事務，在壓測結果中，若是響應時間較長時，就能夠對每個事務進行分析，看哪一個事務耗時最長。
• 明確監控對象：針對每一個場景，明確可能的性能瓶頸點（好比數據庫查詢、Web服務器服務轉發、應用服務器等）、須要監控的對象，好比TPS、平均響應時間、點擊率、併發鏈接數、CPU、內存、IO等。
• 定義測試策略：

²        明確性能測試的類型：須要進行哪些類型的性能測試，好比負載測試、壓力測試、穩定性測試等。

²        明確性能測試場景的執行順序，通常是先執行單場景，後執行混合場景測試。

²        若是是進行壓力測試，還須要明確加壓的方式，好比按照開始前5分鐘，20個用戶，而後每隔5分鐘，增長20個用戶來進行加壓。

• 性能測試工具的選取：

²        性能測試工具備不少，常見的性能測試工具備Loadrunner、Jmeter、nGrinder等，那麼如何來選取合適的性能測試工具呢

l         通常性能測試工具都是基於網絡協議開發的，因此咱們須要明確待壓測系統使用的協議，儘量和被壓測系統的協議保持一致或者至少要支持被壓測系統的協議。

l         理解每種工具實現的原理，好比哪些工具適用於同步請求的壓測，哪些工具適用於異步請求的壓測。

l         壓測時明確鏈接的類型，好比屬於長鏈接仍是短鏈接、通常鏈接多久能釋放

l         明確性能測試工具併發加壓的方式，好比是多線程加壓仍是多進程加壓，通常採用的都是多線程加壓。

• 明確硬件配置和軟件配置：

²        硬件配置通常包括：服務器的CPU配置、內存配置、硬盤存儲配置、集羣環境下還要包括集羣節點的數量配置等。

²        軟件配置通常包括：

l         操做系統配置

l         應用版本配置：應用版本要和線上保持一致，特別是中間件、數據庫組件等的版本，由於不一樣版本，其性能可能不同。

l         參數配置：好比web中間件服務器的負載均衡、反向代理參數配置、數據庫服務器參數配置等。

²        網絡配置：通常爲了排除網絡瓶頸，除非有特殊要求外，一般建議在局域網下進行性能測試，而且明確壓測服務器的網卡類型以及網絡交換機的類型，好比屬於千兆網卡或者交換機屬於百兆交換機仍是千兆交換機等，這對咱們之後分析性能瓶頸會有很大的幫助，在網絡吞吐量較大的待壓測系統中，網絡有時候也很容易成爲一個性能瓶頸。

1.3.4   編寫性能測試案例

性能測試案例通常是對性能測試方案中性能壓測場景的進一步細化，通常包括以下：

l         預置條件：通常指執行此案例須要知足何種條件，性能測試案例才能夠執行。好比性能測試數據須要準備到位、性能測試環境須要啓動成功等。

l         執行步驟：詳細描述案例執行的步驟，通常須要描述包括測試腳本的錄製和編寫、腳本的調試、腳本的執行過程（好比如何加壓、每一個加壓的過程持續多久等）、須要觀察和記錄的性能指標、須要明確性能曲線的走勢、須要監控哪些性能指標等。

l         性能預期結果：描述性能測試預期須要達到的結果，好比TPS須要達到多少、平均響應時間須要控制到多少之內、服務器資源的消耗須要控制在多少之內等。

Robot Framework自動化測試框架核心指南電子版試讀