前言

看到目前線上大多日志框架測(cè)評(píng)大多從宏觀角度，直接對(duì)比異步同步的吞吐量，但是沒有考量到更深層的淘汰機(jī)制、等待策略、隊(duì)列長(zhǎng)度等對(duì)性能表現(xiàn)的影響，因此本文將從更多的角度對(duì)比及分析兩款日志框架的性能表現(xiàn)，通過JProfiler+Jmeter壓測(cè)及數(shù)據(jù)采集，從線程占用、鎖占用、宏觀耗時(shí)等多維度可視化數(shù)據(jù)。

性能測(cè)試

logback

同步日志

耗時(shí)

未經(jīng)過任何調(diào)優(yōu)，采用Logback默認(rèn)配置得出上圖，一百萬條日志打印耗時(shí)(ms)，如圖：?jiǎn)尉€程下性能最佳，耗時(shí)隨線程數(shù)增加而下降。

線程占用

單線程

無阻塞狀態(tài)

多線程

多線程打印日志時(shí)，會(huì)產(chǎn)生大量線程阻塞，線程越多阻塞狀態(tài)越多

四線程

八線程

十六線程

鎖占用

線程發(fā)生多次占用鎖的情況。查看Logback源碼可得知，檢查容量、放入隊(duì)列、取出隊(duì)列都需要在取得鎖后進(jìn)行

異步日志（隊(duì)列擴(kuò)容）

樣本數(shù)100萬，隊(duì)列長(zhǎng)度110萬

耗時(shí)

線程占用

單線程

多線程

四線程

八線程

十六線程

鎖占用

每次寫入隊(duì)列都需要占用鎖，同時(shí)Appender從隊(duì)列取出也需要占用鎖

異步日志（半隊(duì)列擴(kuò)容）

樣本數(shù)100萬，隊(duì)列長(zhǎng)度50萬，不啟用拋棄策略

耗時(shí)

線程占用

單線程

多線程

寫入耗時(shí)明顯增長(zhǎng)，寫入過程仍然發(fā)生阻塞狀態(tài)

四線程

八線程

十六線程

鎖占用

log4j2

同步日志

樣本數(shù)100萬，Logger到Appender串行執(zhí)行，輸出到文件

耗時(shí)

線程占用

線程產(chǎn)生長(zhǎng)時(shí)間的等待，主要是緩沖環(huán)溢出后無法寫入，生產(chǎn)者根據(jù)等待策略進(jìn)入等待狀態(tài)

單線程

單線程生產(chǎn)不需要爭(zhēng)搶鎖，因此全程無阻塞

多線程

整體來看，阻塞的時(shí)間隨著線程增多而增多，因此多線程對(duì)同步日志影響極大，性能損失嚴(yán)重

四線程

八線程

十六線程

后續(xù)監(jiān)控因阻塞時(shí)間太長(zhǎng)跳過

鎖占用

阻塞在Appender上的輸出流上，輸出流是在單線程中執(zhí)行的

異步日志（隊(duì)列擴(kuò)容）

樣本數(shù)100萬，隊(duì)列長(zhǎng)度110萬，使用Yield等待策略

耗時(shí)

單線程占用最高，耗時(shí)隨線程數(shù)增加而縮短，直到線程數(shù)超過CPU核數(shù)。單線程耗時(shí)與logback相當(dāng)，多線程耗時(shí)比logback縮短了2倍

線程占用

單線程與多線程使用都無阻塞狀態(tài)，保證足夠的隊(duì)列容量，能使日志操作保持高吞吐和低延遲，避免阻塞等待

單線程

多線程

四線程

八線程

使用與宿主機(jī)CPU核數(shù)相等的線程數(shù)，日志寫入過程無阻塞、無線程切換

十六線程

異步日志（日志淘汰策略）

樣本數(shù)100萬，隊(duì)列長(zhǎng)度50萬，啟用拋棄策略

耗時(shí)

線程占用

隊(duì)列長(zhǎng)度50萬，正常來說應(yīng)與半隊(duì)列擴(kuò)容一樣，產(chǎn)生阻塞現(xiàn)象，但啟用了日志淘汰策略，無法寫入隊(duì)列的將直接拋棄不阻塞等待

單線程

多線程

四線程

八線程

十六線程

異步日志（半隊(duì)列擴(kuò)容）

樣本數(shù)100萬，隊(duì)列長(zhǎng)度50萬，使用Yield等待策略

耗時(shí)

當(dāng)隊(duì)列滿后，大幅影響了響應(yīng)時(shí)間，吞吐量依賴Appender的消費(fèi)性能

線程占用

單線程記錄日志時(shí)，前半段隊(duì)列未滿時(shí)生產(chǎn)線程一直處于工作狀態(tài)，后半段因消費(fèi)能力跟不上生產(chǎn)能力，導(dǎo)致隊(duì)列滿載，生產(chǎn)線程開始出現(xiàn)等待狀態(tài)

單線程

等待的時(shí)間比多線程少，是因?yàn)閱尉€程下日志生產(chǎn)速度慢，同時(shí)日志也在倍消費(fèi)

多線程

前一段時(shí)間可以維持高性能工作，但后面隊(duì)列滿后開始發(fā)送等待，導(dǎo)致耗時(shí)延長(zhǎng)

四線程

八線程

十六線程

鎖占用

并未發(fā)現(xiàn)日志記錄過程中發(fā)生鎖占用

異步日志（等待策略）

樣本數(shù)100萬，隊(duì)列長(zhǎng)度50萬，使用Timeout等待策略

耗時(shí)

線程占用

未產(chǎn)生阻塞狀態(tài)

單線程

多線程

因Timeout等待策略使用了鎖，因此產(chǎn)生一定的阻塞

四線程

八線程

十六線程

鎖占用

使用Timeout等待策略時(shí)，放入隊(duì)列前會(huì)取鎖，進(jìn)行消費(fèi)者線程喚醒動(dòng)作

性能調(diào)優(yōu)

異步日志

無論是logback還是log4j2，使用異步日志可以大幅提高日志操作耗時(shí)，間接提高業(yè)務(wù)方整體耗時(shí)

日志可靠性

異步日志無法保證日志可靠性，系統(tǒng)意外關(guān)閉會(huì)丟失隊(duì)列中的日志，因此要求高可靠的日志，應(yīng)該選擇數(shù)據(jù)庫或者M(jìn)Q來保證

Logback

通過

<appender name="async-log-all" class="ch.qos.logback.classic.AsyncAppender">

設(shè)置

Log4j2

通過

System.setProperty("Log4jContextSelector", "org.apache.logging.log4j.core.async.AsyncLoggerContextSelector")

設(shè)置

日志拋棄策略

將溢出隊(duì)列的日志拋棄，保持穩(wěn)定的響應(yīng)速度。對(duì)業(yè)務(wù)方來說能保持良好、穩(wěn)定的日志服務(wù)，但需要容忍一定的日志丟

Log4j2

通過

System.setProperty("log4j2.AsyncQueueFullPolicy","Discard")

設(shè)置

Logback

通過<discardingThreshold>指定拋棄日志的閾值

拋棄邊界

當(dāng)隊(duì)列剩余容量小于閾值后，將拋棄ERROR以下的日志

禁用拋棄策略

設(shè)置為0則表示不拋棄，業(yè)務(wù)線程等待隊(duì)列空間可用后寫入

默認(rèn)閾值

默認(rèn)閾值為隊(duì)列長(zhǎng)度的20%，隊(duì)列長(zhǎng)度100閾值為20

日志等待策略

Log4j2獨(dú)有的特性，指定隊(duì)列滿時(shí)，生產(chǎn)者進(jìn)行等待的行為，需要在不開啟拋棄策略下進(jìn)行

TimeoutWaitStrategy

Log4j2默認(rèn)的等待策略，通過Object.wait等待隊(duì)列騰空。在放入隊(duì)列時(shí)會(huì)加鎖，不推薦使用。

YieldWaitStrategy

通過

System.setProperty("log4j2.asyncLoggerWaitStrategy","Yield")

設(shè)置。通過System.yield()等待隊(duì)列騰空，比Timeout等待策略更高效，比Busy等待策略更節(jié)能

隊(duì)列容量

由性能測(cè)試可知，不適用日志拋棄策略下，隊(duì)列滿載后生產(chǎn)線程將阻塞等待隊(duì)列騰空，直接影響業(yè)務(wù)方的效率

Logback

通過<queueSize>指定隊(duì)列長(zhǎng)度，Logback固定使用ArrayBlockingQueue作為隊(duì)列

Log4j2

通過

System.setProperty("log4j2.asyncLoggerRingBufferSize","x")

指定

二次方長(zhǎng)度

RingBuffer內(nèi)部計(jì)算位置時(shí)通過二進(jìn)制方式計(jì)算，使用二的指數(shù)長(zhǎng)度可以提高計(jì)算速度

長(zhǎng)度計(jì)算公式

暫未找到統(tǒng)一標(biāo)準(zhǔn)的計(jì)算公式，本人覺得可以通過(日志峰值TPS#消費(fèi)TPS)*15*60來計(jì)算

承載容量

這個(gè)公式的含義是：應(yīng)用15分鐘以峰值去生產(chǎn)的日志可以全部被隊(duì)列容納

成本

從成本的角度看，隊(duì)列不應(yīng)該無限量地預(yù)估，在保證系統(tǒng)不受到容量影響下，盡可能地使用小的長(zhǎng)度，節(jié)省內(nèi)存開支

響應(yīng)時(shí)間

一般應(yīng)用不應(yīng)該長(zhǎng)時(shí)間在峰值運(yùn)行，如果出現(xiàn)長(zhǎng)時(shí)間在峰值運(yùn)行，則應(yīng)該進(jìn)行水平拓展分散請(qǐng)求壓力。因此容納15分鐘之內(nèi)的峰值，可以有足夠時(shí)間讓運(yùn)維響應(yīng)，進(jìn)行水平拓展分散壓力。

消費(fèi)瓶頸

日志消費(fèi)TPS由Appender消費(fèi)效率決定，當(dāng)日志TPS超過消費(fèi)TPS時(shí)，日志將開始在隊(duì)列中堆積

消費(fèi)TPS

某個(gè)Appender在一秒內(nèi)消費(fèi)的日志數(shù)量，舉FileAppender為例，每條日志消費(fèi)花費(fèi)100微妙(性能好的主機(jī)可以到60)，一秒可以消費(fèi)1萬條日志，即消費(fèi)TPS為1萬

請(qǐng)求TPS

一般Web應(yīng)用不會(huì)承載超過消費(fèi)TPS的流量。假設(shè)每個(gè)請(qǐng)求打印五條日志，則需要5000以上的TPS才能產(chǎn)生日志堆積

消費(fèi)者優(yōu)化

日志TPS長(zhǎng)時(shí)間(15min+)超過消費(fèi)TPS的場(chǎng)景下，應(yīng)該對(duì)消費(fèi)能力進(jìn)行優(yōu)化，使用輕量級(jí)的Appedner、簡(jiǎn)單的Layout、日志拋棄策略、過濾器、業(yè)務(wù)方規(guī)范等方面進(jìn)行優(yōu)化

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論