開頭
寫這篇文章的目的其實有2個：
1.總結自己的工作收獲工作中的經驗
2.也是應我離開公司后，測試小伙伴們的訴求，給他們一些指點吧（楊霞，雅潔，高巧，還有雪晴，希望此篇文章能給你們提供一些幫助，助你們在測試的道路上越走越好）
好了，廢話說了很多，回歸正題，性能測試的工具有很多，但是總體還是思路和設計主導，再帶入工具。此次我將依據工作中的實際場景，總結一下性能測試怎么入手
分類
性能測試主要分為幾個大塊
1. 服務器
2. 數據庫
3. 中間件
4. 負載均衡
以上是需要測試到的地方
服務器與場景設計
計算TPS
任何系統都是需要人來使用的，那么有一個比較通用的公式能夠很好的依據系統的預計使用壓力，來設計我們的場景
系統的壓力指標最直接的也就是TPS（系統吞吐量），按照二八原則，公式如下：
TPS=日交易次數*80%/（日開放的交易時間秒*20%）
舉個例子：一個系統每天業務請求有2百萬次，24小時開放。 那么對應的TPS為：2000000*80%/（24*3600*20%）= 3.7 次/秒
如果對系統性能需求較為嚴苛，則可以遵循一九原則
設計場景
在知道系統吞吐量以后，可以開始設計實際使用場景
1）單交易目標TPS=腳本配置占比*總目標TPS
2）單交易並發用戶數=單交易目標TPS*ART
3）實際並發用戶數=單交易並發用戶數上取整
4）交易間隔時間=實際並發用戶數/單交易目標TPS
由此設計出單業務TPS，單交易並發用戶數，交易間隔時間。
場景運用
單交易最大壓力：
上面我們已經獲得了單業務的吞吐量，按照單業務的並發量開始加壓，壓力不能小於單業務的吞吐量，並試探服務器的最大承受極限
服務器最大資源閾值達到系統最大處理能力時，為最大承受極限，最大tps和最大並發數依據最大處理能力填寫，運行時間為半小時到一小時
單交易穩定性：
單個請求保持最大壓力，持續12小時，測試系統穩定性
混合場景穩定性：
混合場景則按照計算的實際最大總吞吐量，按照百分比分配的單場景混合腳本運行，服務器指標和單交易穩定性一致
業務指標：
其中業務指標也需要考慮，如服務器硬性指標和業務指標任何一項未達到，則不合格
至此，場景設計完成。
數據庫
數據庫壓力在性能測試中也至關重要，比如MySQL連接數，表的大小，insert和查詢時間速度等
就用MySQL為例
通過分析，在一定數據量下，針對數據庫的基本操作的時間不能超過上圖范圍
至於數據庫工具，大家可以用Jmeter提供的現成的JDBC來進行測試
當然如果基於python技術棧，也可以自己寫個時間方法，查詢方法來的更快更靈活，並且可通過matpoltlib繪制直觀的趨勢圖
同樣數據庫服務器的系統資源同樣重要
中間件
中間件此處以Tomcat為例
其中JDBC連接等待數，線程繁忙率比較重要
JDBC連接等待數和繁忙率：http://ip:port/probe
通過tomcat的probe工具，放入webapp下，輸入對應的ip地址，對性能進行監控（此處不詳細介紹probe，自行查資料）
負載均衡：
負載均衡有很多工具，用的比較多的應該有nginx反向代理。
此處我們要關注的不是nginx怎么配置與怎么工作，很簡單，此處我們只需要知道輸入和輸出，並且對比
在最大TPS下，使用服務器性能監控工具（nmon等工具，自行查資料），對比多服務器之間的cpu使用差異率即可
最后：
大體的性能測試入手與思路介紹完成，具體應該根據實際業務情況，使用環境和工具做進一步的詳細設計。
locust，sql性能等，完全可以自行寫適合公司的框架來進行性能測試（個人建議）
如要轉載，請注明出處
