性能交流扣扣群：317765580
性能測試的三個核心原理是什么？
1.基於協議。性能測試的對象是網絡分布式架構的軟件，而網絡分布式架構的核心是網絡協議
2.多線程。人的大腦是單線程的，電腦的cpu是多線程的。性能測試就是利用多線程的技術模擬多用戶去負載
3.模擬真實場景。用戶的訪問時間，訪問頻率都不是固定的。
性能測試的核心關注點是什么？
1.用戶關注。響應時間，穩定性、可恢復性
2.運維關注。服務器/數據庫資源使用，服務器端處理速度,系統能否支撐7*24小時
3.測試關注。最大訪問用戶數量，最大業務處理數量，內存資源能否正常回收
4.開發關注。代碼：算法、sql語句
簡述性能測試流程
1.分析性能需求。挑選用戶使用最頻繁的場景來測試，比如：登陸，搜索，下單等等。確定性能指標，比如：事務通過率為100%，TOP99%是5秒，最大並發用戶為1000人，CPU和內存的使用率在70%以下
2.制定性能測試計划，明確測試時間(通常在功能穩定后，如第一輪測試后進行)和測試環境和測試工具
3.編寫測試用例
4.搭建測試環境，准備好測試數據
5.編寫性能測試腳本
6.性能測試腳本調優。設置檢查點、參數化、關聯、集合點、事務，調整思考時間，刪除冗余腳本
7.設計測試場景，運行測試腳本，監控數據
8.分析測試結果，收集相關的日志提單給開發
9.性能測試回歸
10.編寫測試報告
如何確定系統最大負載？
通過負載測試，不斷增加並發，隨着並發數的增加，各項性能指標也會相應產生變化，當出現了性能拐點，比如，當用戶數達到某個數量級時，響應時間突然增長，那么這個拐點處對應的用戶數就是系統能承載的最大用戶數。Jmeter中可以用rps定時器或者階梯加壓線程組。
你們系統哪些地方(哪些功能)做了性能測試？
選用了用戶使用最頻繁的功能來做測試，比如：登陸，搜索，提交訂單
你們的並發用戶數是怎么確定的？
1）會先上線一段時間，根據收集到的用戶訪問數據進行預估
2）根據需求來確定，使用高峰時間段，注冊用戶數，單次響應時間等
你們性能測試在什么環境執行？
搭建一套獨立的性能測試環境進行測試
你們性能測試什么時間執行？
基准測試：功能測試之后，系統比較穩定的時候再做。
負載測試：夜深人靜，系統沒人用的時候
怎么分析性能測試結果？
首先查看事物通過率，然后分析其他性能指標，比如，確認響應時間，事務通過率，CPU等指標是否滿足需求；如果測試結果不可信，要分析異常的原因，修改后重新測試
think_time的作用是什么？
在業務基准測試中模擬用戶的思考時間
在確定性能測試結果可信后，如果發現以下問題，按下面提供的思路來定位問題
問題一：響應時間不達標
查看事務所消耗的時間主要在網絡傳輸還是服務器，如果是網絡，就結合Throughput(網絡吞吐量)圖，計算帶寬是否存在瓶頸，如果存在瓶頸，就要考慮增加帶寬，或對數據的傳輸進行壓縮處理；如果不存在瓶頸，那么，可能是網路不穩定導致。如果主要時間是消耗在服務器上，就要分別查看web服務器和數據庫服務器的CPU，內存的使用率是否過高，因為過高的CPU，內存必定會造成響應時間過長，如果是web服務器的問題，就把web服務器對應上對應的用戶操作日志取下來，發給開發定位；如果是數據庫的問題，就把數據庫服務器對應上對應的日志取下來，發給開發定位。
問題二：服務器CPU指標異常
1：關注cpu利用率和負載情況，如果利用率過低負載過高，那么可能是進程隊列過多，造成了阻塞
2：關注上下文切換，如果主動切換過多，那么可能是內存/IO瓶頸；如果被動切換過多，那么可能時間片不夠，可以考慮調整進程優先級來增加時間片
問題三：內存溢出，進程消失
1：觀察堆內存的年輕代與老年代空間分配是否合理，調整內存參數
2：swap空間是否不足，觸發了oomkiller
問題四：程序在多用戶運行時嚴重超時，甚至提示連不上服務器。
程序可能是單線程處理機制，后續的線程全部在排隊等待
問題五：如何識別系統瓶頸？
1：隨着負載的增加，吞吐量是否能持續穩定的上升，找到吞吐量下滑的那個點
2：隨着負載的增加，響應時間是否開始變長，找到響應時間突然變長的那個點
3：隨着負載的增加，是否開始出現錯誤
常見的施壓模型有哪幾種？
1、並發模式（虛擬用戶模式）
並發是指虛擬並發用戶數，從業務角度，也可以理解為同時在線的用戶數。從客戶端的角度出發，摸底業務系統各節點能同時承載的在線用戶數，可以使用該模式設置目標並發，也就是jmeter工具里面的線程數
2、RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒請求數。RPS 模式即“吞吐量模式”，通過設置每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力。
性能測試的應用領域有哪些？
能力驗證：通過實際的測試結果證明自己系統的預期能力
瓶頸分析：通過一系列的測試手段發現系統的性能瓶頸（並發，負載，壓力，失效恢復）
性能調優：通過一系列的技術手段優化系統性能，包括響應時間，吞吐量，資源利用率
容量規划：為了符合未來的規划預期（用戶數，市場占有率），對資源做相應的調整
jmeter如何設計性能測試場景？
並發測試：基礎線程組（強調單位時間的並發，不存在絕對並發）
基准測試：反復對比結果，驗證調優結果是否通過（tps是否提升，響應時間是否下降）
負載測試：持續不斷地增加負載，發現性能瓶頸（階梯加壓線程組，Concurrency Thread Group）
並發用戶模式的負載：不斷增加並發用戶數，發現瓶頸
吞吐量模式的負載：不斷增加每秒請求數（rps）對服務端施壓，發現tps瓶頸
壓力測試：tps瓶頸點上持續負載
穩定性壓力測試：tps保持高壓穩定。一般取最大tps的80%持續運行
破壞性壓力測試：目的是只需要服務端出現異常
失效恢復測試：出現異常之后，系統可以很快的恢復
容量規划測試：50萬，高峰時間段2小時
tps無法上升原因有哪些？
1.網絡帶寬
在壓力測試中，有時候要模擬大量的用戶請求，如果單位時間內傳遞的數據包過大，超過了帶寬的傳輸能力，就會造成網絡資源競爭，導致服務端接收到的請求數達不到服務端的處理能力上限。
2.連接池
可用連接數太少，造成請求等待。連接池一般分為服務器連接池（比如Tomcat）和數據庫連接池（或者理解為最大允許連接數也行）。
3.GC
如果堆內存分配的不合理，就會導致頻繁的gc，gc會導致線程暫停。尤其是fullgc，會造成線程長時間暫停
4.數據庫配置
高並發情況下，如果請求數據需要寫入數據庫且需要寫入多個表的時候，數據庫的最大連接數不夠，或者寫入數據的SQL沒有索引，或沒有主從分離、讀寫分離，就會導致數據庫事務處理過慢，影響到TPS。
6.硬件資源
包括CPU（配置、使用率等）、內存（占用率等）、磁盤（I/O、頁交換等）
7.壓力機
單機負載能力有限，如果需要模擬的用戶請求數超過其負載極限，會影響TPS（這個時候就需要進行分布式壓測來解決問題）