基準(zhǔn)測(cè)試可幫助您發(fā)現(xiàn)Logback在壓力下的性能

日志記錄對(duì)于服務(wù)器端應(yīng)用程序是必不可少的，但這是有代價(jià)的。 令人驚訝的是，微小的更改和配置調(diào)整對(duì)應(yīng)用程序的日志記錄吞吐量有多大影響。 在這篇文章中，我們將根據(jù)每分鐘的日志條目對(duì)Logback的性能進(jìn)行基準(zhǔn)測(cè)試。 我們將找出哪些追加程序性能最佳，什么是謹(jǐn)慎模式以及Async方法，篩選和控制臺(tái)日志記錄的一些令人敬畏的副作用是什么。 讓我們開始吧。

基準(zhǔn)測(cè)試的基礎(chǔ)

Logback的核心是基于Log4j，并根據(jù)CekiGülcü的愿景進(jìn)行了調(diào)整和改進(jìn)。 或如他們所說， 更好的Log4j 。 它具有本機(jī)slf4j API，更快的實(shí)現(xiàn)，XML配置，審慎的模式以及一組有用的Appender，我將在稍后詳細(xì)介紹。

話雖這么說，但是有許多方法可以使用Logback上可用的不同Appender，模式和模式進(jìn)行記錄。 我們采用了一組常用的組合，并在10個(gè)并發(fā)線程上進(jìn)行了測(cè)試，以找出運(yùn)行速度更快的組合。 每分鐘寫入的日志條目越多，該方法越有效，并且有更多資源可用于為用戶服務(wù)。 這不是一門精確的科學(xué)，但更確切地說，我們已經(jīng)對(duì)每個(gè)測(cè)試運(yùn)行了5次，刪除了頂部和底部的異常值，并取了結(jié)果的平均值。 為了公平起見，所有寫入的日志行也具有相等的200個(gè)字符的長(zhǎng)度。

**所有代碼都可以在GitHub的權(quán)利在這里 。 該測(cè)試在Debian Linux機(jī)器上運(yùn)行，該機(jī)器在具有8GB RAM的Intel i7-860（4核@ 2.80 GHz）上運(yùn)行。

第一個(gè)基準(zhǔn)：同步日志文件的成本是多少？

首先，我們看一下同步和異步日志記錄之間的區(qū)別。 既寫入單個(gè)日志文件，FileAppender都將條目直接寫入文件，而AsyncAppender將條目饋入隊(duì)列，然后寫入隊(duì)列。 默認(rèn)隊(duì)列大小為256，當(dāng)隊(duì)列大小為80％時(shí)，它將停止輸入較低級(jí)別的新條目（WARN和ERROR除外）。

該表在FileAppender和AsyncAppender的不同隊(duì)列大小之間進(jìn)行比較。 異步以500個(gè)隊(duì)列大小排在首位。

• 調(diào)整＃1： AsyncAppender的速度可以比同步FileAppender快3.7倍。 實(shí)際上，這是跨所有附加程序記錄的最快方法。

它的性能比默認(rèn)配置要好，該默認(rèn)配置甚至落后于應(yīng)該最后完成的同步FileAppender。 那么可能發(fā)生了什么？

由于我們是從10個(gè)并發(fā)線程中寫入INFO消息，因此默認(rèn)隊(duì)列大小可能太小，消息可能丟失到默認(rèn)閾值。 查看500和1,000,000隊(duì)列大小的結(jié)果，您會(huì)注意到它們的吞吐量相似，因此隊(duì)列大小和閾值對(duì)他們來說不是問題。

• 調(diào)整＃2：默認(rèn)的AsyncAppender可能導(dǎo)致性能降低5倍，甚至丟失消息。 確保根據(jù)需要自定義隊(duì)列大小和丟棄閾值。

<appender name="ASYNC500" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>500</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="FILE" /> </appender>

**設(shè)置AsyncAppender的queueSize并丟棄Threshold

第二基準(zhǔn)：消息模式真的有作用嗎？

現(xiàn)在，我們想看看日志輸入模式對(duì)寫入速度的影響。 為了公平起見，即使使用不同的模式，我們也使日志行的長(zhǎng)度相等（200個(gè)字符）。 默認(rèn)的Logback條目包括日期，線程，級(jí)別，記錄器名稱和消息，通過嘗試使用它，我們?cè)噲D查看對(duì)性能的影響。

該基準(zhǔn)測(cè)試演示并幫助您了解記錄器命名約定的好處。 請(qǐng)記住，要相應(yīng)地將其名稱更改為您在其中使用的類。

• 調(diào)整＃3：按類名命名記錄器可將性能提高3倍。

取消記錄器或線程名稱后，每分鐘會(huì)增加大約40k-50k條目。 無需編寫您將不使用的信息。 最小化也被證明更有效。

• 調(diào)整＃4：與默認(rèn)模式相比，僅使用“級(jí)別”和“消息”字段每分鐘提供了127k多個(gè)條目。

第三基準(zhǔn)：親愛的審慎，你不會(huì)出來玩嗎？

在審慎模式下，可以從多個(gè)JVM訪問單個(gè)日志文件。 由于需要處理另一個(gè)鎖，因此這當(dāng)然會(huì)影響性能。 我們使用之前運(yùn)行的相同基準(zhǔn)測(cè)試了在2個(gè)JVM上寫入單個(gè)文件的謹(jǐn)慎模式。

謹(jǐn)慎模式會(huì)如預(yù)期般受到打擊，盡管我的第一個(gè)猜測(cè)是影響會(huì)更大。

• 調(diào)整＃5：僅在絕對(duì)需要時(shí)才使用謹(jǐn)慎模式，以避免吞吐量下降。

<appender name="FILE_PRUDENT" class="ch.qos.logback.core.FileAppender"> <file>logs/test.log</file> <prudent>true</prudent> </appender>

**在FileAppender上配置審慎模式

第四個(gè)基準(zhǔn)：如何加快同步日志記錄？

讓我們看看FileAppender以外的同步追加程序如何執(zhí)行。 ConsoleAppender寫入system.out或system.err（默認(rèn)為system.out），當(dāng)然也可以通過管道傳輸?shù)轿募?這就是我們能夠計(jì)算結(jié)果的方式。 SocketAppender通過TCP套接字寫入指定的網(wǎng)絡(luò)資源。 如果目標(biāo)脫機(jī)，則該消息將被丟棄。 否則，它將像在本地生成一樣被接收。 對(duì)于基準(zhǔn)測(cè)試，套接字正在將數(shù)據(jù)發(fā)送到同一臺(tái)計(jì)算機(jī)，因此我們避免了網(wǎng)絡(luò)問題。

令我們驚訝的是，通過FIleAppender進(jìn)行顯式文件訪問比編寫控制臺(tái)并將其通過管道傳輸?shù)轿募嘿F得多。 相同的結(jié)果，不同的方法，每分鐘增加約200k日志條目。 盡管在兩者之間添加了序列化，但SocketAppender的性能與FileAppender相似，但網(wǎng)絡(luò)資源（如果存在）將承擔(dān)大部分開銷。

• 調(diào)整＃6：將 ConsoleAppender管道傳輸?shù)轿募峁┑耐掏铝勘仁褂肍ileAppender高13％。

第五基準(zhǔn)：現(xiàn)在我們可以把它提高一個(gè)檔次嗎？

我們工具欄中的另一個(gè)有用方法是SiftingAppender。 篩選允許將日志分為多個(gè)文件。 我們的邏輯是創(chuàng)建4個(gè)單獨(dú)的日志，每個(gè)日志保存我們?cè)跍y(cè)試中運(yùn)行的10個(gè)線程中的2或3個(gè)日志。 這是通過指示鑒別符（在本例中為logid）來完成的，該鑒別符確定日志的文件名：

<appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <key>logid</key> <defaultValue>unknown</defaultValue> </discriminator> <sift> <appender name="FILE-${logid}" class="ch.qos.logback.core.FileAppender"> <file>logs/sift-${logid}.log</file> <append>false</append> </appender> </sift> </appender>

**配置SiftingAppender

我們的FileAppender再次失敗了。 輸出目標(biāo)越多，鎖的壓力就越小，上下文切換也就越少。 與Async示例相同，日志記錄的主要瓶頸被證明是同步文件。

• 調(diào)整＃7：使用SiftingAppender可使吞吐量提高3.1倍。

我們發(fā)現(xiàn)，實(shí)現(xiàn)最高吞吐量的方法是使用自定義的AsyncAppender。 如果必須使用同步日志記錄，則最好對(duì)結(jié)果進(jìn)行篩選，并按某種邏輯使用多個(gè)文件。 我希望您發(fā)現(xiàn)Logback基準(zhǔn)測(cè)試的見解有用，并希望在下面的評(píng)論中聽到您的想法。

翻譯自: https://www.javacodegeeks.com/2014/07/how-to-instantly-improve-your-java-logging-with-7-logback-tweaks.html

總結(jié)

以上是生活随笔為你收集整理的如何通过7个Logback调整立即改善Java日志记录的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。