背景
需要驗證後端埋點方案是否滿足業務服務接口的性能要求：
延時：200ms (tp95)，QPS：2000。
有大概三臺服務器。
埋點方案
logback發送日誌到kafka，ack=1（partition leader ack了就算髮送成功）
所以我們的希望是logback寫日誌的過程對業務服務性能幾乎無影響。
分析
200ms (tp95)：即95%的請求可以在200ms能響應完成。一秒內可響應5次請求。
QPS：2000：即在峯值到來時，高併發下，可以一秒可處理2000次請求。
綜上，可以反推出整個服務大概可以應對400的併發。有三臺服務器，所以均衡一下，每臺服務器要扛700的qps、140的併發。
驗證方案
1.springboot配置logback，ack=1
2.開發一個接口，忽略業務邏輯（因爲還沒開發完），只有一行代碼，寫一條日誌。
3.jmeter配置壓測方案，配置線程140個，每個線程發送1000次，如何模擬qps=700呢，jmeter提供了常數吞吐量定時器，即以固定吞吐量發送請求，在目標吞吐量上填42000（爲啥是42000稍後介紹），選擇基於“所有活動線程”計算吞吐量。同時添加聚合報告，聚合報告可以查看壓測結果。
4.將springboot的jar包部署在遠程服務器上，本地開啓jmeter執行壓測方案。（如果你是在windows上開啓的jmeter需要把本機的端口上限調大，端口回收時間調短，不然測試一會兒就會發現本地的端口耗盡了）
驗證結果展示
點擊jmeter的聚合報告，顯示如下
發送了140*1000次請求，平均響應時間爲140毫秒，95%的請求在150毫秒內就返回了，吞吐量接近700。咋看性能符合要求。
如何以固定吞吐量壓測
即上文中的42000怎麼來的。jmeter的常數吞吐量定時器，是一個以常數（42000）吞吐量來壓測的。這個常數是分鐘計算的。之前計算過，單機應對140的併發，每秒處理5個任務，那就是意味着qps=140*5=700，qps指的是每秒處理700個任務，那每分鐘就是42000個任務。所以在配置常數吞吐量定時器時，目標吞吐量要設置爲42000，這個吞吐量是基於140個活動線程計算出來的。
通過線程模擬了併發，如果程序性能滿足要求，吞吐量qps就會接近700；如果性能不好，雖然jmeter設置了目標吞吐量，但實際測試時實際的吞吐量就可能不會這麼高，延遲也會加大。
再審視
回看我們的第一張圖，再審視一下，是否滿足性能要求呢？看結果是不太理想的，因爲單寫個日誌就耗費150ms，如果再加上業務邏輯，再訪問個es或者關係數據庫，肯定會超過200ms這個性能要求的。
真的是寫日誌就耗費了150ms麼，再測一下，發現更慢了超過了200ms。那把寫日誌的那一行代碼註釋掉。再測，依然慢。。
why
難道是我的springboot工程有問題，用瀏覽器看一下，也很慢。開個網頁也慢！
這個時候可以懷疑網絡環境了，ping一下遠程服務器ip和百度ip，果然網絡環境不好。本地開發機訪問不了kafka，所以我們只能在遠程服務器上部署jmeter了。
Linux上開啓Jmeter
安裝，直接解壓縮就能用。
開啓壓測只需一條命令：
jmeter -n -t test.jmx -l test.jtl
test.jmx是jmeter測試計劃配置文件，test.jtl是測試結果。jmx文件可以直接從帶UI的操作系統上拷貝過來。生成的結果文件test.jtl可以導入帶UI的操作系統，方便統計和查看。
Jmeter在Linux上的運行截圖（其實不用再導入jtl文件直接看命令行輸出也可以看出個大概）
可以去用kafka查看一下topic裏最新的消息有沒有寫入
kafka-console-consumer.sh --bootstrap-server 'ip1:9092,ip2:9092,...' --topic bigdata_webservice_test
top看下CPU和內存消耗
jps看下對應的程序
313 jmeter的進程、22313 springboot的進程、32303 kafka的進程（在查看生產者發送的消息）
Jmeter導入jtl文件，首先要有一個帶聚合報告的測試計劃，然後導入文件就能得出統計結果。
把上文生成的jtl文件導入JMeter後，可以查看到如下結果：
備註：本地壓測發現：接口中在沒有業務邏輯、只寫埋點日誌的情況下，99%的請求1ms內就會響應，幾乎沒有存在感，不會影響整個業務接口的響應性能。之前測試時，受網絡環境影響，大部分時間消耗在網絡傳輸上了。
Tips:
Jmeter需要你在執行壓測前，先清空一下歷史記錄，不然聚合報告會疊加之前的歷史。
