基準測試可幫助您發現Logback在壓力下的性能

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

基準測試的基礎

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

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

**所有代碼都可以在GitHub的權利在這里 。 該測試在Debian Linux機器上運行，該機器在具有8GB RAM的Intel i7-860（4核@ 2.80 GHz）上運行。

第一個基準：同步日志文件的成本是多少？

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

該表在FileAppender和AsyncAppender的不同隊列大小之間進行比較。 異步以500個隊列大小排在首位。

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

它的性能比默認配置要好，該默認配置甚至落后于應該最后完成的同步FileAppender。 那么可能發生了什么？

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

• 調整＃2：默認的AsyncAppender可能導致性能降低5倍，甚至丟失消息。 確保根據需要自定義隊列大小和丟棄閾值。

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

**設置AsyncAppender的queueSize并丟棄Threshold

第二基準：消息模式真的有作用嗎？

現在，我們想看看日志輸入模式對寫入速度的影響。 為了公平起見，即使使用不同的模式，我們也使日志行的長度相等（200個字符）。 默認的Logback條目包括日期，線程，級別，記錄器名稱和消息，通過嘗試使用它，我們試圖查看對性能的影響。

該基準測試演示并幫助您了解記錄器命名約定的好處。 請記住，要相應地將其名稱更改為您在其中使用的類。

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

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

• 調整＃4：與默認模式相比，僅使用“級別”和“消息”字段每分鐘提供了127k多個條目。

第三基準：親愛的審慎，你不會出來玩嗎？

在審慎模式下，可以從多個JVM訪問單個日志文件。 由于需要處理另一個鎖，因此這當然會影響性能。 我們使用之前運行的相同基準測試了在2個JVM上寫入單個文件的謹慎模式。

謹慎模式會如預期般受到打擊，盡管我的第一個猜測是影響會更大。

• 調整＃5：僅在絕對需要時才使用謹慎模式，以避免吞吐量下降。

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

**在FileAppender上配置審慎模式

第四個基準：如何加快同步日志記錄？

讓我們看看FileAppender以外的同步追加程序如何執行。 ConsoleAppender寫入system.out或system.err（默認為system.out），當然也可以通過管道傳輸到文件。 這就是我們能夠計算結果的方式。 SocketAppender通過TCP套接字寫入指定的網絡資源。 如果目標脫機，則該消息將被丟棄。 否則，它將像在本地生成一樣被接收。 對于基準測試，套接字正在將數據發送到同一臺計算機，因此我們避免了網絡問題。

令我們驚訝的是，通過FIleAppender進行顯式文件訪問比編寫控制臺并將其通過管道傳輸到文件要昂貴得多。 相同的結果，不同的方法，每分鐘增加約200k日志條目。 盡管在兩者之間添加了序列化，但SocketAppender的性能與FileAppender相似，但網絡資源（如果存在）將承擔大部分開銷。

• 調整＃6：將 ConsoleAppender管道傳輸到文件提供的吞吐量比使用FileAppender高13％。

第五基準：現在我們可以把它提高一個檔次嗎？

我們工具欄中的另一個有用方法是SiftingAppender。 篩選允許將日志分為多個文件。 我們的邏輯是創建4個單獨的日志，每個日志保存我們在測試中運行的10個線程中的2或3個日志。 這是通過指示鑒別符（在本例中為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再次失敗了。 輸出目標越多，鎖的壓力就越小，上下文切換也就越少。 與Async示例相同，日志記錄的主要瓶頸被證明是同步文件。

• 調整＃7：使用SiftingAppender可使吞吐量提高3.1倍。

我們發現，實現最高吞吐量的方法是使用自定義的AsyncAppender。 如果必須使用同步日志記錄，則最好對結果進行篩選，并按某種邏輯使用多個文件。 我希望您發現Logback基準測試的見解有用，并希望在下面的評論中聽到您的想法。

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。