在做乙個專案的效能測試，發現增大併發使用者數的時候，響應時間沒有增加，但tps並沒有提公升，這並不符合「邏輯」
執行緒數：300+100
將被測服務擴容且分布不同但宿主機，得到的資料和改變後無差別，且此時的被測服務的cpu、網路等指標均正常，故可以排除該可能性
執行緒數：100
同步所有肉雞的時間後
故排除該可能
單肉雞執行緒數：8+24
注：懷疑單台客戶端肉雞扛不住這樣的併發量，在每個請求後都等待20ms
客戶端肉雞數10
客戶端肉雞數11
很明顯不是這個原因
單肉雞執行緒數：5+15
客戶端肉雞數：11
客戶端肉雞數：1
可以發現單個客戶端肉雞基本上可以處理2600個請求/秒，但是11個客戶端肉雞併發時，被測服務響應但平均值基本不變的情況下，僅僅為3600個/秒，可以猜測是否是因為客戶端肉雞的控制端出現了問題？
單肉雞執行緒數：5+15
客戶端肉雞數：11
和之前的資料對比，發現基本沒有改變
單肉雞執行緒數：5+15
客戶端肉雞數：11
從3600 到 3800，無本質的區別
單肉雞執行緒數：5+15
客戶端肉雞數：11
在平均響應時間增加的情況下，處理的請求猛增為7200個/秒
單肉雞執行緒數：5+15
客戶端肉雞數：11
多次嘗試，發現並沒有較大的改變
從上面資料可以看出，每秒接收的資料量都小於6000kb/s，是否是因為各個客戶端肉雞需要回傳資料給中控端，此時中控端的頻寬不足以支撐資料的回傳導致阻塞？
單肉雞執行緒數：5+15
客戶端肉雞數：11
可以看到請求處理的速度又猛增為10200，通過以上實驗可以發現，主要的影響因素有：
檢視結果樹
中控端網路環境
斷言資訊
聚合報告資訊
吞吐量與網路流量對應關係剖析
吞吐量是衡量網路裝置每秒所能處理的網路流量的乙個指標，而在現實中，網維人員常用流量這個詞來衡量裝置的效能，二者如何對應，到底是1比 1還是1比 2的關係？困擾著很多人。首先我們明確一下概念 流量 是個含糊的詞，它不是裝置的指標術語，在這裡既然是跟吞吐量做對比，我們把它理解為每秒鐘流經某台裝置的資料量...
儲存的吞吐量與IOPS
儲存系統的瓶頸，主要體現在2個方面 吞吐量與iops。名詞解釋 吞吐量英文 throughput，即單位時間內讀取或者寫入資料量的大小。iops 英文全拼 input output operations per second，即每秒進行讀寫 i o 操作的次數，多用於資料庫等場合，衡量隨機訪問的效能...
kafka高吞吐量的原因
kafka的訊息是不斷追加到檔案中的，這個特性使kafka可以充分利用磁碟的順序讀寫效能 順序讀寫不需要硬碟磁頭的尋道時間，只需很少的扇區旋轉時間，所以速度遠快於隨機讀寫 生產者負責寫入資料，kafka會將訊息持久化到磁碟，保證不會丟失資料，kafka採用了倆個技術提高寫入的速度。1.順序寫入 在大...