日誌框架，選擇Logback Or Log4j2？

寫在前面

前段時間寫了一篇文章(文章連接：Logback配置文件這麼寫，TPS提升10倍)，反響還不錯，有不少網友也發表了本身的意見：

總結一下就是：

• logback性能測試同步和異步TPS相差不大
• 都9102年了還在用logback

看到網友的意見後又繼續去作了一波測試和調研

服務器硬件

• CPU 六核
• 內存 8G

測試工具

• JMeter
• JProfile
• APM(New Relic)

logback日誌框架同步和異步測試

以前的測試結果存在如下幾點問題：

• 測試樣本數過少(即線程數和循環執行次數過少，以前線程數爲100，循環1次，樣本總數爲100)
• 測試次數過少，只進行了一次測試，結果存在偶然性
• 兩次測試結果存在污染，樣本數量不同

針對以上問題，從新測試中將線程數修改成200，每次測試中循環100次，樣本總數爲2w，和原來測試的樣本數相比擴大200倍，而且重複測試5次。 新的測試結果以下：

新的測試結果代表，使用logback日誌框架同步和異步輸出日誌方式的TPS相差不大。把數據製做成柱形圖更直觀

可是總以爲異步去寫日誌了，訪問api的線程將更快響應客戶端，TPS就應該有明顯的變化纔對。想不通又去網上查閱了一些資料，有反應說經過APM進行性能監控，同步和異步的TPS將會有較大的差異，TPS必定是會有明顯變化的(吶喊)，因而用APM去監控JMeter發送的請求(JMeter參數設置爲線程數100，Ramp-up Period爲0，循環100次)： APM測試結果以下：

APM監控下，在執行的五分鐘內異步輸出日誌TPS平均爲378rpm

APM監控下，在執行的五分鐘內同步輸出日誌TPS平均爲333rpm 發現TPS同步和異步相比仍是不明顯

又一次證實失敗 雖然想不明白但後來和網友探討了下，醍醐灌頂

TPS變化不明顯的緣由以下： TPS爲每秒處理事務數，每一個事務包括了以下3個過程：

• 用戶請求服務器
• 服務器本身的內部處理
• 服務器返回給用戶

服務器本身的內部請求包括訪問數據庫、處理邏輯和打印日誌，同步和異步中惟一不一樣的就是打印日誌的方式。而從測試結果來看，打印日誌耗時只佔API訪問請求的5.3%，因此縮短打印日誌耗時不能很明顯的提升TPS，由於打印時間和網絡請求、業務處理消耗時間能夠忽略不計 可是測試結果代表，雖然使用異步輸出方式不能明顯提升TPS，可是可以減小打印日誌的耗時。因此使用logback日誌框架仍是推薦使用異步輸出方式

推薦使用log4j2而不是logback

log4j2是log4j 1.x 的升級版，參考了logback的一些優秀的設計，而且修復了一些問題，帶來了一些重大的提高，在異步方面的性能獲得了巨大提高，其除了提供Async Append異步實現外還提供了Async Log異步實現，其中Async Append異步實現方式和logback的異步實現差很少，而Async Log基於LMAX Disruptor庫，實現了一個高性能的異步記錄器。本次測試中log4j2異步實現是基於Async Log。 JMeter測試參數和以前的logback測試同樣，線程數200，循環次數100，重複五輪。而且logj2日誌配置文件基本和logback異步配置相同，知足：

• 控制檯打印日誌
• 分類輸出日誌
• 按天滾動
• 一樣的日誌輸出格式

測試結果以下：

將TPS製做爲柱形圖

TPS提高了6倍！！！，而且打印日誌的耗時都快到統計不出來了 官方提供的測試報告中，log4j2和logback相比性能提高更明顯。附官方測試報告：Asynchronous Loggers for Low-Latency Logging

結論

• 若是使用logback框架，推薦使用異步輸出日誌方式
• 選擇日誌框架，推薦使用log4j2
  
  最後附：測試代碼

---

原創不易，若轉載請標明出處：https://juejin.im/post/5d66a36c518825199701e2ad 做者：何甜甜在嗎

另外最近有個小目標，想升到LV3，以爲文章不錯的點個贊再走嘛

只要人人都獻出一點愛，我就能夠上LV3