效能測試該怎麼做
開頭
寫這篇文章的目的其實有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效能等，完全可以自行寫適合公司的框架來進行效能測試（個人建議）
如要轉載，請註明出處
