性能測試day07_性能瓶頸和分析
https://www.cnblogs.com/leixiaobai/p/9463748.html
其實如果之前都做的很到位的話，那么再加上APM工具(dynaTrace等)，監控到非常細節，那么我們跑一個業務，我們就能完全清楚的知道每個請求的時間，也能知道請求所產生sql的時間，這樣你自然而然都知道時間耗在哪里了，直接就能去調節時間消耗最多的請求了。
對於系統調優分為前后端調優，前端之前有一篇專門講過，現在有些項目用的是胖前端（前端帶有數據庫，請求數據不請求后端，直接請求前端數據庫，前端數據庫會定時刷新同步數據庫，其實這個主要目的就是減少對后端的請求），這里我們主要說一下后端，后端就包括web服務器、app（應用）服務器、DB。也因為基本上所有性能問題都是后端的原因。
影響最大的調優：后端影響最大的性能問題都是DB的問題。那么解決數據庫的性能問題一般都是什么呢？
解決IO問題，數據文件讀取速度的提升，比如硬盤變為ssd。
如果不是IO的問題呢？可以解決讀寫分離，對於讀可以采用redis.
那么如果還不行呢？就要考慮優化sql了，通過sql的執行計划（看sql的執行過程及時間）->判斷是否有索引->分析影響最大和最易調優和組合（可以冗余屬性，對於多表查詢的數據可以適當加多一個字段在表里存放，盡量避免多表查詢）
最易調優：
代碼調優（一般代碼的開銷是cpu），因為代碼是自己寫的，所以最容易調優。
配置和應用平台的調整。
組合調優（讓系統整體都沒有明顯瓶頸）：
有資源不用是浪費；
無節制的調優是毫無意義的，要考慮性價比。
性能調優模型必講->理發師模型
通過數據我們可以做出兩張關系圖，第一張是用戶數和響應時間的圖，這邊我們想一想為什么響應時間會持續上升呢？是不是處理能力一定的情況下，出現了排隊的情況，類似於cpu隊列。第二個圖是用戶和TPS的關系圖，可以知道，處理能力恆定，一旦處理能力飽滿開始排隊，響應時間處理按照處理時間開始堆疊。其實理發師模型就是理想系統的原型圖，特別適合我們去分析研究性能問題。
那么好了，如果我們想要調優，本質上就是提升資源，也就是理發師的個數對不對？那么假設增加理發師人數10倍，那么處理能力就會提升10倍嗎？這個不一定，因為出現了多個理發師的時候，就會出現理發師調度的問題？是不是就需要管理人員？那么就意味着部分人員不能做理發師需要單獨拿出來做管理或者其他，那么從原則上來講提升了10倍的人數后處理能力會低於之前的10倍處理能力吧。所以在理發師人數增多的過程中，剛開始由於要進行任務調度，有可能tps出現稍微下滑的現象。而且理發師增多，那么隊列也就能排的越長，那么出現各種問題的概率也就越大。那么為了避免這個問題怎么辦呢？可以通過異步隊列（比如MQ）進行處理。
在做性能測試時候，
我們一般會先做單用戶串行負載，如果長時間跑下來響應時間沒有變化，那么說明不存在排隊或者資源泄露的問題。（下圖的A點）
然后再做一個理想的小用戶性能測試，如果此時響應時間隨着用戶上升也上升了一段時間后又平穩說明了什么呢？此時我們需要查看TPS，如果響應時間上升的時候，TPS也上升又說明了什么呢？那么是不是有可能對於一個業務有多個因素影響，其中一個因素比較慢，但是其他的都比較快，所以總體來講是慢的但是tps依舊沒到瓶頸點。下圖是常見的用戶數和響應時間還有TPS的關系圖，在我們性能測試過程中出現的三者關系圖都可以參考這個圖來看，B點就是最大處理能力的點，C點是客戶無法接受的響應時間點。
如何判斷調優，實際上就是A、B、C三點的右移，在同場景下如果結果右移證明調優成功。不過大家也要知道不是負載最高就一定是有瓶頸，因為每一種架構都有該架構的性能上限的。
我們平時做性能的時候，一般都會做事務對吧，以登陸為例，假設我們登陸TPS為100時，響應時間為5s，那么我們知道是哪里用了5秒嗎？實際上這只是一個時間的總和（前端、應用端、數據庫端、網絡等時間總和），那么此時我們就需要拆分這個時間，怎么做呢？還記得我之前說的APM監控嗎？一般的APM都是很貴的，所以一般需要我們自己打點，我們可以讓開發幫我們在做每一件事情都記錄時間點，假設登陸，那么我們可以記錄總的后端處理時間，然后讓開發呈現在頁面或者以其它形式給我們，然后再對數據庫處理返回記錄一個時間，那么后端的應用端和數據庫端的時間我們就能差不多知道了。如果開發將時間拋出在了界面，那么我們就可以通過關聯先拿到這個值，然后再通過lr_user_data_point將該時間值記錄下來，在場景測試中，我們可以查看User Defined Data Points可以進行查看。（如果不清楚lr函數使用可以百度）
其實上面的打探針操作就相當於我們做了個小的APM，如果記錄的時間差不丟界面的話也可以丟日志里面，然后我們把日志丟influxdb里面進行排序讀取出來也是可以的。
性能測試執行：
入手
環境（軟硬件、數據、參數）
記錄環境、數據
跑一下（看看系統大概性能，了解整體系統情況）
簡單分析（前端工具，刷新看看性能，評估瓶頸點和響應時間）
數據整理（分析大概的瓶頸點）
重現定位問題（層層探針，定位基於監控）
調優（記住調優不是測試的工作，如何協調開發是調優的關鍵以及自己的見識決定了調優）
報告（思路清晰，測試目的決定報告）
更多調優的具體思路可以查看下阿里雲的測試分析及調優：https://help.aliyun.com/document_detail/29342.html?spm=a2c4g.11186623.6.612.5oUhZg