1 性能測試目的
性能測試的目的：驗證軟件系統是否可以達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，以優化軟件。linux
最後起到優化系統的目的性能測試包括以下幾個方面：web
1.評估系統的能力:測試中獲得的負荷和響應時長數據能夠被用於驗證所計劃的模型的能力，並幫助作出決策正則表達式
2.識別體系中的弱點：受控的負荷能夠被增長到一個極端的水平並突破它，從而修復體系的瓶頸或薄弱的地方數據庫
3.系統調優:重複運行測試，驗證調整系統的活動是否獲得了預期的結果，從而改進性能數組
檢測軟件中的問題:長時間的測試執行可致使程序發生因爲內存泄漏引發的失敗，揭示程序中隱含的問題或衝突緩存
4.驗證穩定性(Resilience)、可靠性（Reliability）:在一個生產負荷下執行測試-必定的時間是評估系統穩定性和可靠性是否知足要求的惟一方法服務器
2 性能測試常見分類
性能測試包括負載測試、強度測試、容量測試等網絡
2.1負載測試（Load Testing）
負載測試是指經過測試系統在資源超負荷狀況下的表現，來發現設計上的錯誤或驗證系統的負載能力。架構
負載測試的目標是肯定並確保系統在超出最大預期工做量的狀況下仍能正常運行負載測試還要評估性能特徵，如響應時長、事務處理速率併發
2.2強度測試（Stress Testing）：壓力測試
壓力測試對系統不斷施加壓力的測試，是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試。
好比測試一個web站點在大量負荷下，什麼時候系統的響應會退化或失敗。
2.3容量測試(Volume Testing)
容量測試肯定系統可處理同時在線的最大用戶數
針對上述 負載測試、壓力測試、容量測試 舉個例子
例：一我的背X斤
負載測試：200斤狀況下，是否能堅持5分鐘
壓力測試：200,300,400... 斤狀況下，他的表現，何時失敗，失敗以後什麼表現，從新扛200是否正常
容量測試：在堅持5分鐘的狀況下，他一次最多能扛多少斤
3 性能測試的常見指標
常見的兩種架構進行軟件測試：B/S、C/S
3.1 B/S架構-常見性能指標
對於B/S架構的軟件，通常會關注以下Web服務器性能指標
| 概念 |
說明 |
| Avg Rps |
平均每秒鐘的響應次數=總請求次數/秒數 |
| Avg time to last byte per terstion(mstes) |
平均每秒業務腳本的迭代次數 |
| Successful Rounds |
成功的請求 |
| Failed Rounds |
失敗的請求 |
| Successful Hits |
成功的點擊次數 |
| Failed Hits |
失敗的點擊次數 |
| Hits Per Second |
每秒點擊次數 |
| Successful Hits Per Second |
每秒成功的點擊次數 |
| Failed Hits Per Second |
每秒失敗的點擊次數 |
| Attempted Connections |
嘗試鏈接數 |
| Throughput |
吞吐率 |
3.2 C/S架構-常見性能指標
對於C/S架構的程序，因爲軟件後臺一般爲數據庫，因此咱們更注重數據庫的測試指標。
除了表格裏面的概念，還有部分指標：CPU佔用率、內存佔用率、數據庫鏈接池等
| 概念 |
說明 |
| User Connections |
用戶鏈接數，也就是數據庫的鏈接數量 |
| Number of Deadlocks |
數據庫死鎖 |
| Butter Cache Hit |
數據庫Cache的命中狀況 |
4 性能測試結果分析
4.1如何分析性能測試結果
- 分析在整個性能測試執行期間，測試環境是否穩定正常。
例如，測試期間運行Jmeter的及其CPU佔用率常常達到100%（或內存佔用很高）、測試網絡出現擁塞致使響應延遲、待測系統參數配置錯誤（JDBC鏈接池等）.....
2. 檢查jmeter測試腳本參數設置是否合理、檢查jmeter運行模式是否合理。
例如，線程組的參數Ramp-Up Period(in seconds)設置爲0或1，jmeter就會瞬間啓動該線程組下的全部虛擬用戶，會爲待測服務器形成巨大的壓力，輕則致使服務器響應時長超長，重則致使部分虛擬用戶等待響應超時而報錯。
3. 檢查測試結果是否暴露出了系統瓶頸。
性能測試分析的原則：由表及裏、由內而外、抽絲剝繭
響應時長，主要包括2部分：服務器響應時長(應用服務器、數據庫服務器的響應時長)、網絡響應時長。
4.2如何藉助監聽器發現性能缺陷
4.2.1圖形結果(Graph Results)
| 概念 |
說明 |
| 樣本數目 |
總共發送到服務器的請求數 |
| 最新樣本（黑色） |
表明時間的數字,是服務器響應最後一個請求的時間(當前採樣響應時長) |
| 吞吐量(綠色) |
服務器每分鐘處理的實際請求數 |
| 平均值(藍色) |
總運行時間除以發送到服務器的請求數（平均採樣響應時長） |
| 中間值（紫色） |
表明時間的數字，有一半的服務器響應時間低於該值而另外一半高於該值 |
| 偏離(紅色) |
服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分佈 |
測試人員能夠經過增長併發線程數或減小腳本中的延遲，來找到系統支持的最大吞吐率。
圖形結果中比較有參考價值的字段是：平均值、偏離、吞吐量。
4.2.1.1平均值
隨着併發壓力的加大，以及時間延長，系統性能所發生的變化。正常狀況下，平均採樣響應時長曲線應該是平滑的，並大體平行於圖形下邊界。
可能存在性能問題的平均值：
①平均值在初始階段跳升，然後逐漸平穩起來。
一是系統在初始階段存在性能缺陷，須要進一步優化，如數據庫查詢緩慢
二是系統有緩存機制，而性能測試數據在測試期間沒有變化，如此一來一樣的數據在初始階段的響應時長確定較慢；這屬於性能測試數據準備的問題，不是性能缺陷，需調整後在測試
三是系統架構設計致使的固有現象，例如在系統接收到第一個請求後，纔去創建應用服務器到數據庫的連接，後續一段時間內不會釋放鏈接。
②平均值持續增大，圖片變得愈來愈陡峭
一是可能存在內存泄漏，此時能夠經過監控系統日誌、監控應用服務器狀態等常見方法，來定位問題。
③平均值在性能測試期間，忽然發生跳變，而後又恢復正常
一是可能存在系統性能缺陷
二是可能因爲測試環境不穩定所形成的（檢查應用服務器狀態【CPU佔用、內存佔用】或者檢查測試環境網絡是否存在擁塞）
4.2.1.2偏離
觀察採樣響應時長標準差，能夠判斷數據的分佈是否均勻。理想狀態是平滑的。
4.2.1.3 吞吐量
服務器每分鐘處理的實際採樣數。首先經過增長併發線程數或減小腳本中的延遲，來找到系統支持的最大吞吐率。而後將系統實際支持的最大吞吐率和預期吞吐率進行比較，以便確認系統表現是否知足用戶需求。
4.2.2斷言結果(Assertion Results)
斷言結果試圖會展現每一個採樣攜帶的標籤，若是斷言有問題，會進行顯示。
4.2.3查看結果樹(View Results Tree)
查看結果樹會以樹的方式來展現全部採樣響應結果，測試人員能夠經過它來查看任何採樣的響應。
查看結果數通常用於調試性能測試腳本。還能夠經過查詢結果，利用正則表達式，從響應結果中提取數據。
4.2.4用表格查看結果
爲每個採樣結果建立一行，可是會佔用較多內存。
在「用表格查看結果」中，測試人員能夠看到採樣時間、系統響應時長、字節數等，且能夠肯定問題採樣發生的準確時刻。
4.2.5聚合報告（Aggreate Report）
部分概念以下：
| 概念 |
說明 |
| Label |
說明是請求類型，如Http，FTP等請求 |
| #Samples |
也就是圖形報表中的樣本數目，總共發送到服務器的樣本數目 |
| Average |
也就是圖形報表中的平均值，是總運行時間除以發送到服務器的請求數（平均響應時間） |
| Median |
也就是圖形報表中的中間值，是表明時間的數字，有一半的服務器響應時間低於該值而另外一半高於該值 |
| 90%line |
是指90%請求的響應時間比所得數值還要小 |
| Min |
是表明時間的數字,是服務器響應的最短期 |
| Max |
是表明時間的數字,是服務器響應的最長時間 |
| Error% |
請求的錯誤百分比 |
| Throughput |
也就是圖形報表中的吞吐量，這裏是服務器每單位時間處理的請求數，注意查看是秒或是分鐘 |
| KB/sec |
是每秒鐘請求的字節數（數據傳輸量） |
| Throughput |
也就是圖形報表中的吞吐量，這裏是服務器每單位時間處理的請求數，注意查看是秒或是分鐘 |
聚合報告綜合判斷系統性能是否知足要求。比較關心的幾個統計值，包括平均響應時長、90%閾值、吞吐率（每秒完成請求數）、錯誤率。
PS:90%line的定義：
一組數由小到大進行排列，找到他的第90%個數（假如是12），那麼這個數組中有90%的數將小於等於12 。
用在性能測試的響應時間也將很是有意義，也就是90%請求響應時間不會超過12 秒。
4.2.6聚合圖形(Aggregate graph)
聚合圖形與聚合報告一致，區別在於聚合圖形有生成的圖表。
4.2.7概要報告(summary report)
| 概念 |
說明 |
| Label |
採樣標籤 |
| #Samples |
標籤名相同的總採樣數 |
| Average |
請求(事務)的平均響應時間 |
| Min |
標籤名相同的採樣中，最小的響應時長 |
| Max |
標籤名相同的採樣中，最大的響應時長 |
| Std.Dev. |
採樣響應時長的標準差 |
| Error% |
事務發生錯誤的比率 |
| Throughput |
該吞吐率以每秒/分鐘/小時發生的採樣數來衡量（TPS） |
| KB/sec |
吞吐量以每秒KB來衡量（即每秒數據包流量） |
| Avg.Bytes |
以字節爲單位的採樣響應平均大小(平均數據流量) |
4.2.8服務器性能監控設置
JMeter使用plugins插件進行服務器性能監控，對服務器的 CPU、內存、Swap、磁盤 I/O、網絡 I/O 進行監控。客戶端添加CPU監控Permon Metrics Collector，服務器端開啓代理，在HTTP請求的時候，就能進行服務器資源的監控狀況。
4.2.8.1服務器插件下載
訪問網址https://jmeter-plugins.org/downloads/old/，下載三個文件。其中客戶端插件JMeterPlugins-Standard和JMeterPlugins-Extras(目前我使用的版本是1.4.0)，
訪問網址https://jmeter-plugins.org/wiki/Start/，下載服務器端插件ServerAgent的。
4.2.8.2插件客戶端配置
解壓客戶端的兩個文件，進入其路徑JMeterPlugins-Extras(Standard)-1.3.1\lib\ext，複製JmeterPlugins-Extras.jar(JmeterPlugins-Standard.jar)兩個文件，放到JMeter客戶端的lib/ext文件夾中,打開JMeter，可在監聽器中看到Permon Metrics Collector，客戶端配置成功。
4.2.8.3插件服務器端配置
將ServerAgent-2.2.1.jar上傳到被測服務器，解壓，進入目錄，Windows環境，雙擊ServerAgent.bat啓動；linux環境執ServerAgent.sh啓動，默認使用4444端口，出現以下狀況
即服務端配置成功。
11-4.Permon Metrics Collector監控的執行