golang的性能測試Benchmark
go test 自帶有三種測試：
- 功能測試（單元測試）
- 基準測試 （性能測試）
- 實例測試 （舉例測試）
今天主要是寫一下基準測試也就是我們的性能測試實踐相關放案。
基準測試是測量一個程序在固定工作負載下的性能狱从。
在Go語言中鱼炒，基準測試函數(shù)和普通測試函數(shù)寫法類似男韧，但是以Benchmark為前綴名勘天，并且?guī)в幸粋€testing.B類型的參數(shù)滩报；testing.B參數(shù)除了提供和*testing.T類似的方法宝惰，還有額外一些和性能測量相關的方法。
它還提供了一個整數(shù)N粱腻，用于指定操作執(zhí)行的循環(huán)次數(shù)庇配。
func BenchmarkAdapter_GetReport(b *testing.B) {
a := &Adapter{
Server: "127.0.0.1:9094/tenant",
}
for i := 0; i < b.N; i++ {
b.ReportAllocs() // 這里可以直接調(diào)用 ReportAllocs 方法，就省去了再命令行中輸入 -benchmem 绍些，用于查看內(nèi)存分配的大小和次數(shù)
_, _ = a.GetReport("devices", "appsinfo", "")
}
}
然后在命令行輸入如下：
go test -bench=GetReport
又或者直接填入測試函數(shù)名：
go test -bench=BenchmarkAdapter_GetReport
最終顯示數(shù)據(jù)如下：
goos: darwin
goarch: amd64
pkg: safeuem/report/service/adapter
BenchmarkAdapter_GetReport-4 500 2351618 ns/op 20770 B/op 301 allocs/op
PASS
ok safeuem/report/service/adapter 2.741s
- BenchmarkAdapter_GetReport-4 ：
這里的-4中的4 表示最大 P 數(shù)量捞慌，最大 P 數(shù)量相當于可以同時運行 goroutine 的邏輯 CPU 的最大個數(shù)。這里的邏輯 CPU柬批，也可以被稱為 CPU 核心卿闹，但它并不等同于計算機中真正的 CPU 核心，只是 Go 語言運行時系統(tǒng)內(nèi)部的一個概念萝快，代表著它同時運行 goroutine 的能力。
對應 golang 就是 GOMAXPROCS 的值著角。這個你可以自行設置揪漩，可以通過調(diào)用 runtime.GOMAXPROCS 函數(shù)改變最大P數(shù)量，也可以在命令行 go test 加入 -cpu=2 吏口。
- 500 2351618 ns/op
顯示每次調(diào)用 GetReport 函數(shù)花費 2.351618毫秒 奄容，是執(zhí)行 500次 的平均時間。
1s=1000ms=1000000us=1000000000ns
因為基準測試驅(qū)動器開始時并不知道每個基準測試函數(shù)運行所花的時間产徊，它會嘗試在真正運行基準測試前先嘗試用較小的N運行測試來估算基準測試函數(shù)所需要的時間昂勒，然后推斷一個較大的時間保證穩(wěn)定的測量結果
- 20770 B/op 301 allocs/op
表示平均500此種，每次分配了內(nèi)存為 20770 B(字節(jié)) = 20.28KB = 0.0198MB 和 每次調(diào)用分配了 301次
1MB=1024KB
1KB=1024B
- 2.741s
表示測試總耗時舟铜。
小提示：
其實這里的總耗時戈盈，其實默認是1s，當測試次數(shù)逐漸遞增到時間剛好超過1s 時測試就會停止谆刨，并顯示測試塘娶，這里是500次。
當然如果你的本身的測試函數(shù)運行一次就已經(jīng)大于了1s,為了提高測試的精確性痊夭，你可以在命令行輸入 :
go test -bench=GetReport -benchtime=5s
jmeter 壓力測試
首先要安裝 請看鏈接不多說
如果下載頁面進不去 移步到此處下載即可
注意 ： 一定要配置好java的環(huán)境變量才開始壓測哦刁岸！
運行啟動如圖所示：
1. 你可以開始配置要測試的http接口：
2. 線程數(shù)的配置：
3. 建立HTTP請求接口：
4. 建立監(jiān)控器 數(shù)據(jù)展示
可以建立三個查看，一般我建立聚合報告看看就可以了她我。
聚合報告數(shù)據(jù)說明：
來看如圖所示的數(shù)據(jù)：
中文版
英文版
這里我的線程數(shù)改變了 2 虹曙。
Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性迫横，這里顯示的就是 Name 屬性的值
-
Samples：表示你這次測試中一共發(fā)出了多少個請求，如果模擬10個用戶酝碳，每個用戶迭代10次矾踱，那么這里顯示100，每個用戶只迭代一次就是10了击敌。我這里自然是 2.
Average：平均響應時間（單位ms介返，1s=1000ms）——默認情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時沃斤，也可以以Transaction 為單位顯示平均響應時間
Median：中位數(shù)圣蝎，也就是 50％ 用戶的響應時間
90% Line：90％ 用戶的響應時間
Min：最小響應時間
Max：最大響應時間
Error%：本次測試中出現(xiàn)錯誤的請求的數(shù)量/請求的總數(shù)
-
Throughput：吞吐量——默認情況下表示每秒完成的請求數(shù)（Request per Second），如果你的接口超過了每秒請求一次就會按照每分鐘展示衡瓶， 當使用了 Transaction Controller 時徘公，也可以表示類似 LoadRunner 的 Transaction per Second 數(shù)
Received KB/Sec：每秒從服務器端接收到的數(shù)據(jù)量，相當于LoadRunner中的Throughput/Sec
Send KB/Sec: 每秒向服務器端接發(fā)送的數(shù)據(jù)量哮针。
所以如圖中的線程數(shù)為2的測試中关面，平均每次響應時間為 554 毫秒相當于半秒，吞吐量為每秒處理了 1.9 次十厢，額等太。。蛮放。很渣的性能缩抡。
因為這個接口本來就沒有高并發(fā)場景要求，而且里面有個比較麻煩的遞歸查詢操作很消耗性能的包颁。
加大壓力進行測試
那么如果出現(xiàn)較多的訪問該接口瞻想，較高并發(fā)訪問性能是如何的呢。
來個小 50 試試呢娩嚼。
好吧蘑险，這個接口性能確實很差。岳悟。佃迄。平均一個接口處理要6s的時間。
具體分析原因：
- 一個是遞歸耗性能
- 另一個應該是Cassandra數(shù)據(jù)庫I/O是性能瓶頸贵少，pool可以從10調(diào)大到100試試和屎。
將Cassandra連接池pool調(diào)為100壓測數(shù)據(jù)
將線程數(shù)設置為200壓測數(shù)據(jù)如下：
果然性能處理要好很多了。
