阿里巴巴質量技術新人手冊又更新了！本期分享的最經常使用的性能測試，買買買，也要服務器穩穩穩！ java
概念&目的
本週分享的性能測試，主要面向的是服務端的性能測試。web
性能測試是從業務中提取壓測模型，而後利用壓測工具按照模型製造壓測流量，並對目標應用集羣進行施壓，在施壓過程當中觀察應用集羣的性能表現和發掘性能瓶頸的測試行爲。算法
當前性能測試主要分爲線上壓測和線下壓測。線上壓測主要經過全鏈路壓測執行，線下壓測是單機(或者小集羣)壓測。全鏈路壓測請看全鏈路壓測章節，本節主要討論通用性能測試方案和流程。數據庫
經常使用指標
1. 虛擬用戶
虛擬用戶，模擬真實業務邏輯步驟的虛擬用戶，虛擬用戶模擬的操做步驟都被記錄在壓測腳本里。壓測腳本用於描述虛擬用戶在場景中執行的操做。跨域
2. Transaction壓測事務
事務是性能測試腳本的一個重要特性。要度量服務器的性能，須要定義事務，每一個事務都包含事務開始和事務結束標記。事務用來衡量腳本中一行代碼或多行代碼的執行所耗費的時間。能夠將事務開始放置在腳本中某行或者多行代碼的前面，將事務結束放置在該行或者多行代碼的後面，在該腳本的虛擬用戶運行時，這個事務將衡量該行或者多行代碼的執行花費了多長時間。緩存
3. TPS每秒事務數
TPS(Transaction Per Second)每秒鐘系統可以處理的交易或事務的數量，它是衡量系統處理能力的重要指標。tomcat
備註：在平常工做中也會用到TPS和QPS，在應用層，全部的請求均可以用QPS或者TPS來表示；但在DB層，TPS和QPS有區別，QPS指的是select的請求量，TPS指的是insert、update和delete的請求量安全
4. Peak PV 高峯Page View
即PV峯值，指一天中PV數達到的最高峯。性能優化
5. Concurrency併發
併發分爲狹義和廣義兩類。狹義的併發，即全部的用戶在同一時刻作同一件事情或操做，這種操做通常針對同一類型的業務，或者全部用戶進行徹底同樣的操做，目的是測試數據庫和程序對併發操做的處理。服務器
廣義的併發，即多個用戶對系統發出了請求或者進行了操做，可是這些請求或操做能夠是不一樣的。對整個系統而言，仍然有不少用戶同時進行操做。
狹義併發強調對系統的請求操做是徹底相同的，多適用於性能測試、負載測試、壓力測試、穩定性測試場景;廣義併發不限制對系統的請求操做，多適用於混合場景、穩定性測試場景。
6. 壓測場景
爲了模擬真實用戶的業務處理過程，從被壓測業務中抽取出目標壓測接口，並封裝成壓測腳本，該抽出出來的目標壓測接口即爲一個壓測場景。
7. Response Time響應時間（RT）
響應時間是指從客戶端發一個請求開始計時，到客戶端接收到從服務器端返回的響應結果結束所經歷的時間，響應時間由請求發送時間、網絡傳輸時間和服務器處理時間三部分組成。
8. Think Time思考時間
模擬正式用戶在實際操做時的停頓間隔時間。從業務的角度來說，思考時間指的是用戶在進行操做時，每一個請求之間的間隔時間。在測試腳本中，思考時間體現爲腳本中兩個請求語句之間的間隔時間。
9. CPU資源
CPU資源是指性能測試場景運行的這個時間段內，應用服務系統的 CPU資源佔用率。CPU資源是判斷系統處理能力以及應用運行是否穩定的重要參數。應用服務系統能夠包括應用服務器、Web服務器、數據庫服務器等。
10. Load負載
系統平均負載，被定義爲在特定時間間隔內運行隊列中的平均進程數。若是一個進程知足如下條件則其就會位於運行隊列中:
-
它沒有在等待 I/O 操做的結果。 -
它沒有主動進入等待狀態(也就是沒有調用「wait」)。 -
沒有被中止(例如:等待終止)。
性能測試策略
1. 模擬生產線真實的硬件環境。
架設與生產環境類似的性能測試環境，使用物理機做爲服務器。例如，使用4核CPU、8G內存的機器模擬生產環境的應用服務器；使用共用存儲的數據庫服務器等。
2. 服務器置於同一機房，最大限度避免網絡問題。
全部性能測試的服務器都放置在同一個機房，屬於同一個網段，服務器與服務器之 間的網絡交互經過交換機進行。
3. 以 PV 爲切入點，經過模型將其轉換成性能測試可量化的 TPS。
互聯網的特色，是在線用戶不斷變化，很難統計到具體某個應用的在線用戶數；可是頁面是固定的，能夠統計的。用戶U訪問了P頁面的行爲，是能捕獲的。換句話，對於頁面 P，無論當前有100個用戶，仍是1000個用戶在使用，頁面的Page View都是能夠統計到的。所以，以PV爲性能測試切入點，做爲性能測試的突破口。經過這種方式，能夠將頁面流量直接轉化成Page View，做爲性能測試的預期目標，而削弱在線用戶數和併發用戶數。獲得PV數值以後，再經過PV計算模型、PV->TPS轉換模型，將它轉化成測試工具能夠衡量的指標TPS，從而使複雜的模型變得簡單化、可衡量化。
4. 性能測試數據分爲基礎數據和業務數據兩部分。
性能測試數據庫和功能測試庫相互獨立。性能測試數據分爲基礎數據和業務數據兩 部分。基礎數據，指爲了使表中的數據達到必定的數量級而填充的數據，目的是測試出數據庫索引是否足夠優化、表空間、索引空間是否足夠；業務數據，指爲了使被測系統 可以按業務邏輯運行起來的數據，通俗而言，就是功能測試所使用的數據，目的是測試 出SQL語句是否足夠優化、代碼是否足夠優化等。
5. 日誌等級設置成 warn，避免大量打印日誌對性能測試結果的影響
JAVA 日誌，分爲 info ,debug ,warn ,error 四個級別。打印日誌會消耗服務器的IO，也會消耗硬盤存儲空間。在性能測試過程當中，若是頻繁打日誌，會致使IO消耗大，從而消耗服務器的CPU資源；也會致使日誌文件過大， 寫入困難，程序執行速度變慢等問題。而 info 和 debug 兩個級別，都會打印大量日誌。所以，性能測試過程當中，選擇將日誌等級設置成warn級別，只打印出warn和 error 的日誌，即減小日誌輸入數量，又能監控到性能測試過程當中出現的錯誤，一箭雙鵰。
6. 屏蔽緩存，模擬最壞的狀況
緩存，是頁面性能優化的手段之一。對於非頻繁變化的數據，能夠在容器中緩存起來，提升讀的性能，同時減輕數據庫壓力。緩存必須在數據被訪問事後纔會生效，另外，緩存失效後須要重啓緩存，即在系統剛發佈、從新緩存過程當中，用戶訪問速度會變慢、數據庫壓力也會加大。爲了不相似系統剛上線，數據庫就受到Load太高，甚至面臨崩潰的災難。在性 能測試過程當中，咱們須要模擬沒有緩存的場景。
7. 先單場景，後混合場景，確保每一個性能瓶頸都獲得調優。
性能測試過程當中，選擇先執行單場景，後執行混合場景的策略。單場景執行，能夠詳細測試到某個頁面、某個接口等「單點」的性能，這種方式有 利於定位性能瓶頸，優化代碼。對於使用 HSF 方式通訊的系統來講，這樣的針對性測試效果很是顯著。混合場景，在單場景都優化完成後，按照必定的比例對各類場景進行組合，測試整個應用系統的整體性能表現。其實，單場景和混合場景，兩種都不可缺乏。
8. 拆分問題，隔離分析，定位性能瓶頸。
性能測試過程當中出現的小几率事件，每每隱藏着大的性能瓶頸。爲了精肯定位到瓶 頸，須要將各個應用，或者一個應用的各個環節進行拆分，逐漸隔離掉沒有問題的部分， 而後在可能有問題的部分進行再排查，直到瓶頸定位到爲止。
9. 根據業務系統要求，來判斷被測性能點經過與否。
結合當前系統複雜度和業務能力要求，來評判當前性能點的性能結果是否知足需求。
10. 性能瓶頸
錄入AONE進行跟蹤，對於不能在當前項目中解決的性能 bug，邀請專家組進行風險評估。
性能測試評估
制定性能測試策略以後，如何開展性能測試工做呢？在實施性能測試以前，須要對被測項目作相應的評估。實施前的評估，主要目的是明確是否須要作性能測試和確立性能點，明確該測什麼、指望值是多少。測試指望值也會根據狀況評估，要求被測系統能知足未來必定時間段的壓力。性能測試評估分爲測試前的評估和測試後的評估。這裏重點闡述測試前的評估。主要從如下 4 個維度進行測試前的評估:
-
關鍵業務。 -
日PV量。 -
邏輯複雜度。 -
運營推廣計劃。
1. 關鍵業務
首要維度，是肯定被測項目是否屬於關鍵業務，有哪些主要的業務邏輯點，特別是跟交易鏈路息息相關的功能點。例如，購物車系統，用於購物車瀏覽、購物車添加、購物車刪除、購物車湊單等功能。經過評估，從中篩選出購物車瀏覽和添加這兩個主要業務涉及的功能。若是項目(或功能點)不屬於關鍵業務(或關鍵業務點)，則可轉入第2、3、四個維度進行評估。
2. 日PV量
第二個維度，是界定被測項目各功能點的PV量(或者日請求量)。若是PV量很高，系統壓力很大，並且又是關鍵業務，該項目須要作性能測試；並且其關鍵業務點，能夠被肯定爲性能點。若是PV量不高，系統壓力不大，但倒是關鍵業務點，則依據第三個或第四個維度來判斷。
3. 邏輯複雜度
第三個維度，是斷定被測項目各功能點的邏輯複雜度。若是一個主要業務的PV量不高，可是邏輯很複雜，則也須要經過性能測試。緣由是，在集團龐大的業務系統調用中，當某一個環節響應較慢，就會影響到其它環節，形成雪崩效應。
4. 運營推廣計劃
第四個維度，是根據運營的推廣計劃來斷定待測系統將來的壓力。未雨綢繆、防患於未然、下降運營風險是性能測試的主要目標。被測系統的性能不只能知足當前壓力，更須要知足將來必定時間段內的壓力。所以，事先了解運營推廣計劃，對性能點的制定有很大的做用。例如，運營計劃作活動，要求系統天天能支撐多少PV、多少UV，或者一個季度後，須要能支撐多大的訪問量等等數據。當新項目(或功能點)屬於運營重點推廣計劃範疇以內，則該項目(或功能點)也須要作性能測試。
5. 其它
以上4個評估維護，是相輔相成、環環相扣的，它們合成一個維度集。在實際工做中，應該具體問題具體分析。例如，當一個功能點不知足以上4個維度，但又屬於內存高消耗、CPU 高消耗時，也可列入性能測試點行列。
性能測試類型
隨着單位時間流量的不斷增加，被測系統的壓力不斷增大，服務器資源會不斷被消耗，TPS 值會由於這些因素而發生變化，並且符合必定的規律，性能測試壓力變化模型如圖1所示。
圖1中:
-
a 點：性能指望值 -
b 點：高於指望，系統資源處於臨界點 -
c 點：高於指望，拐點 -
d 點：超過負載，系統崩潰
由上述壓力變化模型，將性能測試分紅狹義的4種類型:
-
a. 性能測試。 -
b. 負載測試。 -
c. 壓力測試。 -
d. 穩定性測試。
1. 性能測試
a點到b點之間的系統性能
定義:狹義的性能測試，是指以性能預期目標爲前提，對系統不斷施加壓力，驗證系統在資源可接受範圍內，是否能達到性能預期。
運用場景：此類型的測試目前最多見。每一個項目的性能點，都須要作性能測試。
2. 負載測試
b點的系統性能
定義：狹義的負載測試，是指對系統不斷地增長壓力或增長必定壓力下的持續時間，直到系統的某項或多項性能指標達到安全臨界值，例如某種資源已經達到飽和狀態等。
運用場景：此類型的測試目前運用得比較少。通常狀況下，是以服務器資源安全臨界值爲界限的測試。若是要模擬某個應用在指定服務器上最大且安全的負載量，則屬於負載測試。
3. 壓力測試
b點到d點之間
定義：狹義的壓力測試，是指超過安全負載的狀況下，對系統不斷施加壓力，是經過肯定一個系統的瓶頸或不能接收用戶請求的性能點，來得到系統能提供的最大服務級別的測試。
運用場景：此類型的測試目前運用得比較少。但對於大型的共享中心或者核心的應用，也會用到。
4. 穩定性測試
a點到b點之間
定義：狹義的穩定性測試，是指被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載必定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定，通常穩定性測試時間爲n*12小時。
運用場景：此類型的測試目前也最多見，針對須要長時間穩定運行的性能點，須要執行穩定性測試。每每在一個項目的性能測試過程當中，會劃分出優先級較高的性能點，作穩定性測試。例如:寶貝詳情頁面等等。
性能測試執行方法
性能測試一般採用先單場景，後混合場景的執行方法。
1. 單場景
針對單個性能測試點，構建一個性能測試場景，而進行的性能測試。單場景適用於性能測試、負載測試、壓力測試、穩定性測試。
2. 混合場景
爲了儘可能模擬生產線上運行的業務壓力或用戶使用場景，測試系統的總體性能是否知足性能需求，把通過必定規則篩選的性能測試點，按照合乎實際邏輯的虛擬用戶請求、併發，組合成一個混合場景。
混合場景的特徵，一般包含兩個或者兩個以上的腳本組，執行時間較長。混合場景一般在穩定性測試、負載測試中使用。
性能監控
性能監控須要實時觀察性能測試過程當中各項指標是否正常，包括應用服務器、數據庫、中間件、網絡等方面，保證測試前提，記錄測試數據，輸出監控結果。更重要的是，監控的過程是發現系統瓶頸的過程，是性能分析、性能經過與否、性能報告輸出等環節的基礎和依賴。
監控須要使用不一樣的工具，結合系統日誌、應用和服務器所反映的多項指標，記錄監控數據。如下闡述了監控指標、監控工具和監控步驟等三個部份內容。
1. 監控指標
性能測試一般須要監控的指標包括:
-
服務器
具體包括CPU、Memory、Load、I/O、Disk等。
-
數據庫
具體包括緩存命中、索引、單條SQL性能、數據庫線程數、數據池鏈接數等。
-
中間件
具體包括線程數、鏈接數、日誌輸出等。
-
網絡
具體包括防火牆、網卡、網線、吞吐量、吞吐率等。
-
應用服務
具體包括JVM內存使用和回收、JAVA內存使用、FullGC頻率、JAVA類裝入和卸載、日誌、線程運行狀態(阻塞、等待、正常運行)等。
-
性能監控指標
具體包括用戶執行狀況、場景狀態、事務響應時間、TPS、Load、CPU分析圖表等。
-
測試機資源
具體包括CPU、Memory、網絡、日誌輸出、磁盤空間、負載生成器評估等。
2. 監控工具
性能測試一般採用下列工具進行監控:
-
JStat
Jstat是JDK自帶的一個輕量級小工具。全稱「Java Virtual Machine statistics monitoring tool」，它位於java的bin目錄下，它主要利用了JVM內建的指令對Java應用程序的資源和性能進行實時的命令行的監控，包括了對Heapsize和垃圾回收情況的監控。可見，Jstat是輕量級的、專門針對JVM的工具，很實用。
-
JConsole
JConsole是一個用JAVA寫的GUI程序，用來監控VM，並可監控遠程的VM，易用且功能強大。具體可監控JAVA內存、JAVA CPU使用率、線程執行狀況、加載類概況等，JConsole須要在JVM參數中配置端口才能使用。因爲是GUI程序，界面可視化，這裏就不作詳細介紹。
-
JMap
Jmap是一個能夠輸出全部內存對象的工具，甚至能夠將VM中的heap以二進制輸出成文本，能夠監控JAVA程序是否有內存泄漏。
-
JProfiler
JProfiler分析工具是目前功能相對比較全的JAVA剖析工具(profiler)。它能夠詳細的剖析CPU、線程和內存的使用信息。
JProfiler可提供許多IDE整合和應用服務器整合功能。JProfiler直觀式的界面讓你能夠方便的找到性能瓶頸、抓住內存泄漏(memoryleaks)、並解決多線程的問題。能夠對內存的GC的資源回收器作深刻的分析，能夠輕易找出內存泄漏；
JVM內存的快照(snapshot)模式可讓未被引用(reference)的對象、稍微被引用的對象、或在終結(finalization)序列的對象都清晰地呈現出來。
性能分析
性能分析從性能測試分析原則、分析信息來源、分析標準。
1. 分析原則
在分佈式架構下，性能瓶頸分析也變得相對困難。針對不一樣的應用系統、不一樣的測試目標、不一樣的性能關注點，根據性能指標的表現，採用「拆分問題，隔離分析」的方法進行分析，即逐步定位、從外到內、從表及裏、逐層分解、隔離排除。
性能分析，可按如下順序: 中間件瓶頸(tomcat參數配置、數據庫參數配置等)->應用服務日誌->本應用的性能瓶頸(代碼、SQL語句、索引、業務邏輯、線程池設置、算法)->服務提供者的性能瓶頸->相關聯的底層存儲應用的性能瓶頸
注:以上是比較通用的分析過程，具體性能測試查找瓶頸過程當中，須要具體問題具體分析。
2. 分析信息來源
a) 監控工具所採集的信息。包括壓測工具產出的數據以及監控的機器數據。具體爲：TPS、響應時間、用戶併發數、JVM內存、FullGC頻率、CPU利用率、Load等。b) 應用服務器的日誌。包括本應用和遠程應用的錯誤日誌、超時日誌等。c) 項目配合人員所提供的信息。包括數據庫監控信息、開發人員提供的代碼邏輯信息等。
3. 分析標準
經過性能指標的表現形式，分析性能是否穩定。好比: a) 響應時間是否符合性能預期，表現是否穩定。b) 應用日誌中，超時的機率，是否在可接受的範圍以內。c) TPS維持在多大的範圍內，是否有波形出現，標準差有多少，是否符合預期。d) 服務器CPU、內存、Load是否在合理的範圍內，等等。
性能測試流程
測試流程中的主要活動描述以下:
-
評估是否須要進行性能測試：在項目立項前的技術方案階段，PTM/PM和PDM評估出是否須要作性能測試。 -
性能測試資源分配：當前主要由各業務線的開發和功能測試同窗負責進行性能測試。 -
制定性能測試計劃：根據項目(平常)計劃和功能測試計劃，制定性能測試計劃。 -
編寫性能測試設計方案：在UC評審以後，邀請PM、PDM、測試負責人，一塊兒細化性能測試需求，編寫性能測試方案。 -
評審性能測試設計方案：組織性能測試設計方案評審會議，邀請PM、系統設計人員、測試負責人、DBA等共同參與。評審主要是針對測試目標、測試策略和測試數據進行確認，並提出改進意見，達成一致 -
提交代碼、配合搭建環境、配合數據準備：線下測試，可在aone的項目環境中搭建性能測試環境，同時準備壓測數據和壓測腳本。 -
執行性能測試：第一輪功能測試經過以後，執行性能測試，執行腳本須要符合規範。分析性能測試結果，找到性能瓶頸，配合開發人員進行性能調優，天天產出性能測試日報，並判斷性能測試結果是否知足指望 -
性能調優：PM、性能測試工程師、DBA共同參與性能測試調優方案的制定工做。代碼的調優工做，由PM或者PM指定開發人員完成。 -
編寫性能測試報告：編寫性能測試報告，闡明性能測試目標、性能測試環境、性能測試數據構造規則、性能測試策略、性能測試結果、性能測試調優說明、性能測試過程當中遇到的問題和解決辦法等。
- To Be Continued -
前方劇透！！！
《技術質量新人手冊》
成爲測試多面手
-
如何作好跨域項目？ -
穩定性保障&大促保障 -
如何從0-1實現本身的效能創新，思路和解法 -
測試分析的主要方法 -
測試用例設計之常見風險點
本文分享自微信公衆號 - 阿里巴巴技術質量（AlibabaTechQA）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。