1、 測試背景：由於業務需求，開發決定部署乙個redis高可用方案codis，使用codis3.2版本。
2、 **：非常簡單的redis讀寫方法，讀和寫分開測。
3、基本架構：一台應用伺服器（12核48g），單例項proxy（48核198g），三例項zk集群（48核198g），三組codis-server，每組各乙個codis-server，具體配置資訊如下。
4、開始壓測，結果發現，tps最高在1800左右，100併發時平均響應時間為53ms，200併發時平均響應時間為111ms，tps基本不變，應用伺服器cpu使用率在25%左右，codis和redis伺服器壓力非常小，典型的存在效能瓶頸的現象，開始定位瓶頸。
5、檢視執行緒資訊，發現有很多log4j的鎖，基本定位問題，瓶頸是log4j引起的。也可以確定，log4j使用的是1.x版本，因為這個版本在多執行緒寫日誌時，存在同步鎖，而log4j 2使用了新一代的基於lmax disruptor的無鎖非同步日誌系統。在多執行緒的程式中，非同步日誌系統吞吐量比log4j 1.x高10倍，而時間延遲更低。這也是我們現在都用log4j2的原因。還只是猜測，實驗一下吧。
6、更改log4j日誌級別為off，就是不列印任何日誌，然後重啟。測試結果如下，上周五晚上測試結果讀的tps能到18000+，寫能到20000+，瓶頸在應用伺服器上，今天是下午進行的測試，讀的tps大概就13000，估計可能是網路原因，確實存在晚上比白天網路好很多的情況。
總結：本次測試基本上能了解codis的整體效能，20000的tps是完全能滿足需求的，給開發的建議也就是公升級log4j到log4j2。
ps：redis使用單執行緒，只能使用單核cpu，實際測試中，redis的cpu使用率非常低，單核只用了20%多，所以說redis的效能瓶頸不在cpu上，或許這也是redis是單執行緒的原因。
Codis集群測試
1 測試說明 1.1 背景 當前im架構設計與之前相比有很大不同，當前im將所有狀態資訊儲存在資料層，它的設計假設是資料層高可用，高效能，可擴容 目前im資料層採用redis集群codis搭建。1.2 目標 以下測試針對單機redis和codis進行測試，通過對比分析得到im資料層的擴容能力，測試出...
轉MQTT SERVER 效能測試報告
硬體環境 記憶體4g cpu4核 server及埠 apollo埠 61619 mosquitto 埠 1884 activemq埠 1883 emqtt 埠1885 測試方法 併發測試 192.168.6.156 上用 emqttd benchmark 測試 192.168.6.157 上的各mq...
效能測試中「併發度」的意義 轉）
之前的文章中曾出現過 併發度 這個概念，這個詞不知道是不是我原創，它意在表達 併發 的可能性，是壓力的一種度量。一些同學可能還沒有理解這個概念的意義，下面我們看看它是怎麼來 看過之前文章的同學應該知道，我將 併發 這個容易產生誤解的詞拆分成了 相對併發 和 絕對併發 為什麼這麼做呢？那是因為 絕對併...