原文並未提及kafka的版本 並且測試的消息大小都偏小 測試數據供參考 原文還測試了broker等 原文請移步文章末尾
4.1 producer測試
4.1.1 batch-size
測試結果
測試結論
測試中通過我們增加batch-size的大小，我們可以發現在消息未壓縮的前提下，20000條一批次之后吞吐穩定在19.65M/s。
4.1.2 ack
測試結果
測試結論
4.1.3 message-size
測試結論
測試中通過我們使用兩種不同的消息大小，發現在消息未壓縮的前提下且其他參數一致的情況下，687字節的吞吐量是要優於454字節的，目前我們的兩種消息為此大小，測試中發現當消息大小為4k時效果最優，也基本符合kafka設計用來傳輸10K左右的消息的初衷。
4.1.4 compression-codec
測試結果
測試結論
在batch-size為2w且並發量在3w時，可以看出來不壓縮的吞吐量最好，其他的基本相差不大。
測試結果2
測試結論
我們在后續測試中發現，在batch-size為100w且並發量在10w時，可以看出來snappy和lz4的吞吐量上升幅度明顯，而gzip由於壓縮的費時其吞吐最差，不壓縮的在本測試中的吞吐次之。
測試結果3
測試結論
我們在后續測試中發現，在batch-size為100w且並發量在20w時，lz4的吞吐量優勢明顯達到19w/s，snappy次之為12.8w/s，而gzip由於壓縮的費時其吞吐最差基本在5.8w/s，不壓縮的在本測試中的吞吐也能達到11w/s。
測試結果4
測試結論
在batch-size為100w且並發量在50w時，lz4的吞吐量優勢明顯達到31.3w/s，snappy次之為16.1w/s，而gzip由於壓縮的費時其吞吐最差基本在5.3w/s，不壓縮的在本測試中的吞吐也能達到9.3w/s。
測試結果5
測試結論
在batch-size為100w且並發量在60w時，lz4的吞吐達到37.5w/s，snappy此時下降到10.8w/s，而gzip由於壓縮的費時其吞吐最差基本在5.4w/s，不壓縮的在本測試中的吞吐為9.4w/s。
測試結果6
測試結論
在batch-size為100w且並發量在70w時，lz4的吞吐量下降到達到27.2w/s，snappy次之為13.9w/s，而gzip則繼續保持在5.8w/s，不壓縮則下降到7.1w/s。
測試結果7
測試單副本單分區下的各壓縮的吞吐量：
測試結論
我們這次使用1個分區1個副本的主題，測試中通過我們使用不同的壓縮格式，在其他參數一致的情況下，在並發和batch-size增大到60w和100w的情況下，lz4達到最好的吞吐21.2w/s，而普通不壓縮的方式則維持在6.7w/s。
-
測試結論
本次測試對數據的存儲塊大小未測，但在之前的測試中發現壓縮以及解壓的情況也是lz4算法最優，==lz4壓縮最大時可以達到30w+/s的吞吐，而不壓縮為12w/s,snappy最大為16w/s,gzip最大為5.8w/s==；故后續生產消息時建議采用lz4壓縮，不僅可以節省磁盤，也可以大幅度增加我們的吞吐。
4.1.5 partition
測試結果
分區數越多，單線程消費者吞吐率越小。
測試結論
在我們的broker線程小於partiton數時，隨着線程增多，吞吐上升，而在兩者對等時，達到最優，后續基本穩定，但是由於網絡和磁盤的問題可能會有一些起伏。
4.1.6 replication
測試結果
測試結論
Replication是我們對不同partition所做的副本，它的大小會在ISR中顯示，為了保證數據的安全性，ISR中掉出的版本應該保持在1，所以此處我們從replica為2開始測試。在ack不同時，其數量的多少會對性能造成線性的影響，數量過少會影響數據的可用性，太多則會白白浪費存儲資源，一般建議在2~4為宜，我們設置為3個，既能保障數據的高可用，又避免了浪費過多的存儲資源。
4,1.7 throughout IO
測試結果
測試結論
在主題是一個分區和一個副本時，我們看到在並發50w以下時，隨着並發數增大，吞吐上升，但是在50w以后時，可以看出並發增大反而吞吐降低了，這是因為IO的限制，在高並發的情況下，產生了阻塞而導致。
4.2 consumer測試
4.2.1 thread
測試結果
測試結論
在threads為4時，消費速度最好達到24.1w/s,而后續慢慢平穩。
4.2.2 fetch-size
測試結果
測試結論
4.2.3 partiton
測試結果
測試結論
分區數在kafka中和處理的線程數有一定的關系，當thread小於partition數時，那么可能存在一個thread消費兩個partition，而==兩者一樣或者說thread大於partition時，實際是一一對應關系==。
4.2.4 replication
測試結果
測試結論
數量過少會影響數據的可用性，太多則會白白浪費存儲資源，一般建議在2~4為宜，我們設置為3個，既能保障數據的高可用，又避免了浪費過多的存儲資源。
4.2.5 fetch-thread
測試結論
在我們控制其他條件不變的情況下，我們更改fetch-thread的線程數，可以發現是隨着線程數增多而消費速度加快，在fetch-threads=10時，最優為146.4m/s。
轉載節選自 https://mp.weixin.qq.com/s?__biz=MzI0NTIxNzE1Ng==&mid=2651217964&idx=2&sn=6517a7732ff69f82445c75c4b91a6c6c&chksm=f2a322c7c5d4abd14a6108a2ca6e4913cc5c70a75d803a17d3d3142e9844dde6a514c4ca9f24&mpshare=1&scene=1&srcid=&sharer_sharetime=1569202183520&sharer_shareid=904fe9378619edc63a81ef90022195da&key=7fbd4d18e8fd1c6f03866d845e076c0a849b0b0b04126973151263ddd43588bfa5f951e340a70f9bc15af82bf935e39017d3d1a96999fbcedbc33399c36919e57a4e82f92c43bf150dda1c56178cd207&ascene=1&uin=MTA2MTYyNTc4Mw%3D%3D&devicetype=Windows+7&version=62060834&lang=zh_CN&pass_ticket=ngfhIoUK7ktBYbHIqLZZONtzSK69VqypB3n%2B3xyiyRoRZ%2BLUIf%2B8ewFCZhezQRZL