第一章：性能測試基礎
1.性能測試分類
中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試、應用在服務器端性能的測試。概括起來也就是：客戶端、網絡端、服務端
客戶端就是壓力機；當進行壓力時需要監控客戶端、網絡端、服務端的數據。
第二章：性能測試方法
1.測試策略
l 負載測試
l 壓力測試
l 疲勞強度測試
負載測試：主要指的是模擬系統在正常負載壓力場景下，考察系統的性能指標。這里說的正常負載，主要是指預計系統最大應該支持多大用戶的並發量。通過負載測試，目的是驗證系統是否能滿足預期的業務壓力場景。
壓力測試：在不斷增加並發壓力下系統的性能會變得不可接受，出現性能崩潰的情況，計算出這時的並發值。在加壓策略上，壓力測試會對被測系統逐步加壓，在加壓的過程中考察系統性能指標的走勢情況，最終找出系統在出現性能拐點時的並發用戶數，也就是系統支持的最大並發用戶數。
疲勞強度測試：模擬出長時間系統能承受的最大業務負載量。差異在於前兩者，疲勞強度測試更關注系統在長時間運行下性能指標的變化情況。例如，系統在運行一段時間后，是否會出現事務處理失敗、響應時間增長、業務吞吐量降低、CPU/內存資源增長等問題。
第三章：性能指標
從維度上划分，性能指標主要分為兩大類，分別是業務性能指標和系統資源性能指標
以下的性能指標是常用的指標，隨着對性能要求的提升，需要觀察其他更詳細的數據，比如：其壓力機和服務器的硬件也會影響性能
性能的最總目的：在保證一定的成功率、響應時間的前提下得到業務需要的最大並發數
1.業務性能指標
- 並發用戶數
- 事務成功率
- 事務吞吐率(TPS/RPS)
- 事務平均響應時間
並發用戶數：壓力機模擬同時訪問服務器的用戶數。查看該指標目的：得到服務器最大並發用戶數。
事務成功率：在性能測試周期內，成功的請求數占全部請求數的百分比。查看該目標目的：服務器正確處理事務能力。
事務吞吐率TPS：每秒服務器處理的事務數；該指標需要根據當前並發用戶數、總響應時間去計算該值。查看該指標目的：服務器處理事務的能力。
事務平均響應時間：平均一條請求(事務)所用的時間。查看該目標目的：宏觀查看服務器是否達到理想的並發數
提示：
平均響應時間與TPS是沒有直接關系，具有宏觀的反比關系，隨着並發數提高並超過服務器處理能力，平均響應時間就會升高，TPS則會下降。
這里有一個例子幫助理解兩者的區別：
https://www.cnblogs.com/baihuitestsoftware/articles/6405078.html
2.系統資源性能指標
- 壓力機：CPU利用資源、處理器隊列長度、內存利用率、磁盤IO狀態、網卡帶寬使用情況等；
- 服務器：CPU利用資源、處理器隊列長度、內存利用率、磁盤IO狀態、網卡帶寬使用情況等；
- 數據庫：數據庫連接數、數據庫讀寫響應時長、數據庫讀寫吞吐量等；
- 網絡：網絡吞吐量、網絡帶寬、網絡緩沖池大小；
- 緩存（Redis）：靜態資源緩存命中率、動態數據緩存命中率、緩存吞吐量等；
第四章：引入性能測試工具
性能測試的主要手段：模擬真實業務的壓力對被測系統進行加壓，並同時監控被測系統資源性能指標，研究被測系統在不用壓力情況下的表現，找出其潛在的性能瓶頸。
如何對系統進行加壓，又如何對系統的指標進行監控呢？這里，就需要引入性能測試工具了。
1.性能測試工具的基本組成
現在市面上有很多工具，不管使用哪一款工具，基本都會包含如下幾個核心的功能：
- 壓力生成器（Pressure Generator）
- 結果采集器（Outcome Collector）
- 負載資源監控器（Monitor）
- 結果分析器（Result Analyzer）
原理結構如下圖所示：
壓力發生器：來產生無限壓力地方，相當於無數個測試人員
結果采集器：結果記錄人員
負載控制器：對應的是指揮人員
資源監控器：對應的是若干資源監控人員，監控客戶端、網絡端、服務端
結果分析器：對應的是結果統計人員
壓力發生器是性能測試工具最核心的部分，它主要有兩個功能，一是真實模擬用戶操作，二是模擬有效並發。
大多數性能測試工作人員可能都會忽略的是，當前市面上性能測試工具的壓力發生器基本都是存在缺陷的。
模擬真實用戶操作：瀏覽器在加載網頁的時候，是同時並發多個TCP連接去請求頁面對應的HTTP資源，包括HTML、JS、圖片、CSS，當前流行的瀏覽器普遍會並發6-10個連接。然而，性能測試工具在模擬單個用戶操作的時候，基本上都是單連接串行加載頁面資源。產生的差異在於，假如頁面有100個資源，每個HTTP請求的響應時間約為100毫秒，那么瀏覽器采用6個連接並行加載網頁時大概會需要1.7秒（100/6*100毫秒），而測試工具采用單連接串行加載就需要10秒（100*100毫秒），兩者結果相差十分巨大。這也解釋了為什么有時候我們通過性能測試工具測試得到的響應時間挺長，但是手動用瀏覽器加載網頁時感覺挺快的原因。
有效並發：有效並發就是我們在測試工具中設置了1000虛擬用戶數，實際在服務器端就能產生1000並發壓力。然而現實情況是，很多時候由於測試設備自身出現了性能瓶頸，壓力發生器產生的並發壓力遠小於設定值，並且通常測試工具也不會將該問題暴露給測試人員；如果測試人員忽略了這個問題，以為測試得到的結果就是在設定並發壓力下的結果，那么最終分析得出的結論也就跟實際情況大相徑庭了。不過，我們可以通過保障測試環境不存在瓶頸，使得實際生成的並發壓力盡可能地與設定值一致；另一方面，我們也可以通過在測試過程中監控Web層（例如Nginx）的連接數和請求數，查看實際達到服務器端的並發數是否跟我們的設定值一致，以此來反推壓力發生器的壓力是否有效。
了解這些缺陷的意義在於，我們可以更清楚測試工具的原理，從而更准確地理解測試結果的真實含義。
2.性能測試工具
目前市場上主要流行的是Loadrunner和jmeter，還有一款知名度很低的Locust等等，就這三種分析下優劣：
| \ |
LoadRunner |
Jmeter |
Locust |
| 授權方式 |
商業收費 |
開源免費 |
開源免費 |
| 開發語言 |
C/Java |
Java |
Python |
| 測試腳本形式 |
C/Java |
GUI |
Python |
| 並發機制 |
進程/線程 |
線程 |
協程 |
| 單機並發能力 |
低 |
低 |
高 |
| 分布式壓力 |
支持 |
支持 |
支持 |
| 資源監控 |
支持 |
不支持 |
不支持 |
| 報告與分析 |
完善 |
簡單圖表 |
簡單圖表 |
| 支持二次開發 |
不支持 |
支持 |
支持 |
通過對比，Locust也不怎么樣嘛，資源監控也不支持，報告分析能力也這么弱，那為啥還要選擇它？
授權方式這個就不說了。雖然LoadRunner是商業軟件，價格極其昂貴，但是國內盜版橫行，別說個人，就算是大型互聯網公司，用正版的也沒幾個。
從功能特性的角度講，LoadRunner是最全面的，用戶群體也是最多的，相應的學習資料也最為豐富，不太熟悉性能測試可以先從LoadRunner熟悉性能測試工具各個模塊的概念和功能，再過渡到其他工具。LoadRunner只能在Windows平台使用，並且並發效率比較低，單台壓力機難以產生較高的並發能力。
Jmeter的並發是基於線程，並發效率存在同樣的問題；另外，Jmeter在腳本編寫和描述是基於GUI操作
Locust：
模擬用戶：采用Python腳本描述，並且HTTP請求是基於Requests庫，該庫功能強大使用簡單；除了HTPP(S)協議，Locust也可以測試其他任意協議的系統，只需要采用Python調用對應的庫進行請求買書即可。
並發機制：采用協程（gevent）的機制。采用多線程模擬用戶時，線程數會隨着並發數的增加而增加，而線程之間的切換是需要占用資源的，IO的阻塞和線程的sleep會不可避免的導致並發效率下降。
協程和線程區別：協程避免了系統資源調度，由此大幅度提高了性能，單台普通配置的測試機可以生產數千並發壓力，這是LoadRunner和Jmeter都無法實現的。
Locust功能單薄，特別是在性能指標監控和測試報告圖表方面比較缺失，但是Locust的代碼結構清晰，核心代碼量也只有幾百行，可擴展性不錯，深入挖掘性能測試工具原理非常合適
3. 選擇性能測試工具
根據上面，選擇Locust工具來進行性能測試，性能測試重要的是監控性能數據，增加到持續集成會比較復雜，暫時先不考慮集成到Jenkins里
部署時間：1天
參考資料：
四年性能經驗文章：http://debugtalk.com/post/locustplus-talk-about-performance-test/
百度百科【性能測試】：https://baike.baidu.com/item/性能測試