異步請求的時間怎麼計算：
放入隊列的時間+在消息隊列排隊的時間+拿走後處理的時間
整個消息隊列瓶頸的地方在處理隊列的時間

性能測試概念：
性能測試是通過工具或者手段來模擬正常的，峯值以及異常負載條件來對系統的各項性能指標進行測試

性能測試目的：
1，評估系統的能力：看系統能不能滿足性能指標
2，識別體系中的弱點：系統是否哪個功能或者哪個接口是瓶頸的
3，驗證系統穩定性和可靠性：長時間壓力下系統是否能夠穩定運行
4，系統調優：重複執行性能測試，驗證系統調優是否取得預期效果

性能測試指標：
併發：
狹義：同一瞬間對同一系統發出相同的請求
廣義：同一時間段內對同一個系統發起的多個請求
併發用户數：同一時間段內對同一個系統發起的多個請求的數量

tps:一秒鐘處理來多少個事務，後來演變為一秒鐘處理了多少個請求
qps:一秒鐘系統處理了多少個查詢
事務最早的概念來源於loadrunner,loadrunner中沒有事務就沒有響應時間
jmeter中有沒有事務無所謂，jmeter中是以請求為單位的，本來沒有事務但是可以加事務
事務是自己定義的，可以把一個請求當作一個事務也可以把幾個請求當作一個事務


線程數和用户數，併發數之間的關聯是什麼？
工具（jmeter,loadrunner）概念裏面沒有用户數的概念,jmeter裏面只有線程，loadrunner裏面有線程和進程
工具維度，線程就是操作的用户，但是，線程或者用户不等於併發
當前系統就有200個用户在操作，請問當前200個用户等不等於200個併發，等不等於200個線程？
系統維度，不等於200個併發不等於200個線程

響應時間：
響應時間指的是客户端發出請求到收到響應的整個過程所經歷的。
指從客户端發出一個請求開始時，到客户端接收到從服務器返回的響應結果線束經歷的時間，
響應時間由請求發送時間，網絡傳輸時間和服務器處理時間三部分組成。

n1+n2+n3+n4 網絡傳輸時間
a1+a3+a2 應用程序處理時間 = 應用程序本身的邏輯處理時間+數據庫服務器處理時間
a1+a2+a3+n2+n3 = 接口處理時間
n2+n3+a2 = 數據庫耗時時間
開發埋點所説的接口響應時間 = a1+a2+a3+n2+n3,但是工具所説的響應時間還包括n1+n4+client接收和發送的時間

前端的性能通過工具測試不出來，不同的瀏覽器渲染時間不同，工具不會有渲染時間，
工具可以計算出圖片的下載時間，但是不會測試出頁面渲染時間
測試分為前端性能測試和服務端性能測試
前端是沒有併發的，併發只在服務端，前端看頁面卡頓和渲染

吞吐量：單位時間段內系統接收或者發送的字節數，是網絡上的消耗（loadrunner內指的）
jmeter裏面的吞吐量就是tps
現在吞吐量指單位時間段內的xxx

資源利用率：硬件利用率，軟件利用率

性能測試：
1，目標值：tps  併發數(前提rt確定)  rt(併發數確定)
tps為指標   rt不能超過多少    請求成功率
2，場景  單接口-----是否能滿足目標值   10-15min
        極限值場景----max值 以後的監控報警用  10-15min
        混合場景/鏈路場景-----不同的場景混合，是否會有新的性能問題（線程死鎖，數據庫死鎖，系統瓶頸。。。）  10-15min
        穩定性場景-----內存泄漏/溢出  n*12h


性能測試的容量測試：
功能-----支持最大的單表數據量，mysql支持的最大單表量是200w
系統的併發量