log4j性能 slf4j

最近，Apache社區中一位受人尊敬的成員嘗試了Log4j 2并在Twitter上寫道：

@TheASF ＃log4j2搖搖欲墜 ！ 性能接近瘋狂^^ http://t.co/04K6F4Xkaa

— Mark Struberg（@struberg） 2013年5月7日

（來自Mark Struberg的名言：@TheASF＃log4j2搖搖欲墜！性能接近瘋狂^^ http://logging.apache.org/log4j/2.x/）

在Remko Popma貢獻了一些東西（現在稱為“ AsyncLoggers”）之后不久，發生了這種情況。 某些人可能知道Log4j 2已經具有AsyncAppenders。 它們相似，就像您在Log4j 1和其他日志記錄框架中可以找到的一樣。

老實說：我對新功能并不感到興奮，直到我閱讀了有關其性能的推文并對此感到好奇。 顯然，Java日志記錄有許多目標。 其中： 日志記錄必須和地獄一樣快 。 沒有人希望他的日志記錄框架成為瓶頸。 當然，登錄時總會有成本。 CPU必須執行一些操作。 即使您決定不編寫日志語句，也正在發生某些事情。 預計日志是不可見的。

到目前為止，眾所周知的日志記錄框架在速度上是相似的。 基準畢竟是不可靠的。 我們已經在Apache Logging上建立了一些基準。 有時，一個日志記錄框架會獲勝，有時則是另一個。 但總而言之，您可以說他們都很好
您可以根據自己的喜好進行選擇。 直到我們得到Remko的貢獻，Log4j 2變得“異常快速”。

運行一個線程的小型軟件項目可能不太在乎性能。 運行SaaS時，您根本不知道您的應用何時會吸引到您需要擴展的吸引力。 然后，您突然需要一些額外的電源。

使用Log4j 2，運行64個線程可能為您帶來的日志吞吐量是同類框架的十二倍。

我們說每秒超過18,000,000條消息，而其他消息在同一環境中的發送量大約為1,500,000條或更少 。

我看到了圖表，但簡直不敢相信。 一定有問題。 我重新檢查了。 我自己進行了測試。 就像這樣： Log4j 2的速度非常快。

異步性能，最后閱讀時間：2013年7月19日

截至目前，我們擁有一個日志記錄框架，該框架的性能比那里的其他所有日志記錄框架都要好。 到目前為止，如果速度很重要，那么當我們不想使用Log4j 2時，我們需要證明我們的決定是正確的。 Log4j 2之外的所有其他內容都可能成為瓶頸和風險。 有了這樣一個快速的日志記錄框架，您甚至可以考慮比以前更多地記錄生產中的日志。

最終，我給雷姆科寫了一封電子郵件，問他舊的AsyncAppenders和新的異步記錄器之間到底有什么區別 。

舊的AsynAppenders和新的AsyncLoggers之間的區別

他告訴我：“異步記錄器在做兩件事上與AsyncAppender有所不同，”他們試圖在將日志消息傳遞給另一個線程之前做最少的工作，并且他們使用不同的機制在生產者和生產者之間傳遞信息。消費者線程。 AsyncAppender使用ArrayBlockingQueue將消息傳遞給寫入磁盤的線程， 異步記錄器使用LMAX Disruptor庫 。 尤其是Disruptor的性能差異很大。”

換句話說，AsyncAppender使用先進先出隊列來處理消息。 但是異步記錄器使用了新的東西-Disruptor。 老實說，我從未聽說過。 而且，我從未想過要擴展我的日志記錄框架。 當有人說“擴展系統”時，我想到了數據庫，應用服務器等等，但通常不會記錄日志。 在生產中，記錄已關閉。 故事結局。

但是，雷姆科（Remko）考慮進行日志記錄時進行擴展。

“查看異步記錄器的性能測試結果，您會注意到的第一件事是，某些記錄方式的伸縮性要好于其他方式。 通過更好地擴展，我的意思是當添加更多線程時，您將獲得更多的吞吐量。 如果您添加的每個線程的吞吐量都增加了一個恒定值，那么您將具有線性可伸縮性。 這是非常可取的，但可能很難實現。”他寫道。

“將同步與異步進行比較，您會期望任何異步機制的擴展都比同步日志記錄好得多，因為您不再在生產線程中執行I / O，而且我們都知道'I / O很慢'（而且我會再說一遍）”。

是的，完全是我的理解。 我認為將某些內容發送到隊列就足夠了，而其他的則可以將其接收并編寫消息。 該應用程序將繼續運行。 雷姆科寫道，這正是舊的AsyncAppender所做的：

“使用AsyncAppender，您的所有應用程序線程所需要做的就是創建一個LogEvent對象，并將其放在ArrayBlockingQueue上； 然后，使用線程將這些事件從隊列中移出并完成所有耗時的工作。 即，將事件轉換為字節并將這些字節寫入I / O設備的工作。 由于應用程序線程不需要執行I / O，因此您希望它可以更好地擴展，這意味著添加線程將允許您記錄更多事件。

如果您相信像我一樣，請坐下并深呼吸。 我們錯了。

他寫道：“事實可能并非如此。”

“如果查看所有日志記錄框架的AsyncAppenders的性能數字，您會發現，每當線程數量加倍時，每個線程的吞吐量大約減半。”

“因此，您的總吞吐量幾乎保持不變！ 他告訴我，AsyncAppenders比同步日志記錄要快，但是它們的相似之處在于，當您添加更多線程時，它們都不給您帶來更大的總吞吐量。

它像錘子一樣打在我身上。 基本上，而不是通過添加更多線程來加快日志記錄速度，基本上是：沒有。 畢竟，直到現在Appender都沒有擴展。 我問雷姆科為什么會這樣。

事實證明，隊列并不是在線程之間傳遞信息的最佳數據結構。 作為標準Java庫的一部分的并發隊列使用鎖來確保值不被破壞并確保線程之間的數據可見性。

LMAX破壞者？

“ LMAX團隊對此進行了大量研究，發現這些隊列有很多鎖爭用。 他們發現一個有趣的事情是隊列始終是滿的或空的：如果生產者速度更快，則在大多數情況下您的隊列將是滿的（這本身可能就是一個問題）。 如果您的使用者的速度足夠快，則您的隊列在大多數情況下將是空的。 無論哪種方式，您都將在隊列的開頭或結尾處爭用，生產者和使用者線程都希望更新同一字段。 為了解決這個問題，LMAX團隊提出了Disruptor庫，該庫是用于在線程之間傳遞消息的無鎖數據結構。 這是Disruptor和ArrayBlockingQueue之間的性能比較 ： 性能比較 。”

哇。 經過這些年的Java編程，我實際上再次感覺像是初級程序員。 我錯過了LMAX破壞者，甚至從未考慮使用Queue帶來的性能問題。 我想知道到目前為止我還沒有發現其他性能問題。 我意識到，我不得不重新學習Java。

我問雷姆科，他怎么能找到像LMAX破壞者這樣的圖書館。 我的意思是沒有人編寫軟件，創建隊列類的實例，懷疑其性能并最終在互聯網上搜索“更好的東西”。

還是真的有這種人？

“我如何發現Disruptor？ 簡短的回答是，這全都是錯誤。”他開始道。

“好吧，也許這有點太短了，所以答案更長一些：我的一位同事寫了一個小的記錄器，本質上是在隊列中添加了帶時間戳的日志消息，并帶有后臺線程，這些線程使這些字符串脫離了隊列。并將它們寫入磁盤。 他之所以這樣做，是因為他需要比log4j-1.x更好的性能。 我做了一些測試，發現它更快，我不記得確切多少。 我很驚訝，因為我已經使用log4j多年了，并且從未想到過它會輕易勝過。 在那之前，我一直以為著名的庫會很快，因為……說實話，我只是以為。 因此，這讓我大開眼界。 但是，自定義記錄器在功能上有點過頭，所以我開始四處尋找替代方案。”

“在我開始談論Disruptor之前，我必須坦白一些東西。 我最近回過頭來查看自定義記錄器比log4j-1.x快多少，但是當我測量它時，它實際上要慢一些！ 原來，我一直在將自定義記錄器與log4j-2.0的舊beta（我認為beta3或beta4）進行比較。 這些Beta版中的AsyncAppender仍然存在性能問題（如果您好奇，則為LOG4J2-153）。 如果我將自定義記錄器與log4j-1.x中的AsyncAppender進行了比較，我會發現log4j-1.x更快，并且我不會再考慮了。 但是由于犯了這個錯誤，我開始尋找功能更豐富的其他高性能日志記錄庫。 我沒有找到這樣的日志庫，但是遇到了很多其他有趣的東西，包括Disruptor。 最終，我決定嘗試將具有良好代碼基礎的Log4j-2與Disruptor結合使用。 結果最終被Log4j-2本身接受，其余的，正如他們所說的，已成為歷史。”

“我在這里提到的一件事是彼得·勞瑞（Peter Lawrey）的編年史圖書館 。 Chronicle使用內存映射文件以極低的延遲每秒將數千萬條消息寫入磁盤。 還記得上面我說過的“我們都知道I / O速度很慢”嗎？ 紀事表明，同步I / O可以非常非常快。 ”。

“通過彼得的工作，我遇到了破壞者。 關于Disruptor的資料很多。 只是給您一些提示：

• 馬丁·福勒（Martin Fowler）：LMAX
• 特里莎（Trisha Lee）在引擎蓋下的LMAX上使用 （現在已經有點過時了，但是我所知道的最詳細的資料）
• …像這樣的視頻演示

強烈建議使用Disruptor Google組。

推薦的有關Java性能的閱讀材料通常是：

• 馬丁·湯普森（Martin Thompson）的“機械同情”
• 馬丁·湯普森演講。

Martin Thompson在Java高性能計算的各個方面做了很多文章和演示。 他在使幕后正在進行的復雜工作變得非常出色。”

閱讀此電子郵件后，我的書簽文件夾已滿，并且我很高興有很多起點可以提高我對Java性能的了解。

我應該默認使用AsyncLoggers嗎？

我確定我想使用新的異步記錄器。 這聽起來真是太棒了。 但是另一方面，我有點害怕，甚至有點偏執，要包括新的依賴項或新技術，例如新的Log4j 2 Async Loggers。 我問雷姆科，他是否默認使用新功能，還是僅在少數有限的用例中啟用它們。

“ 我默認使用異步記錄器 ，是的。”他寫道。 “一個用例的時候，你會_not_要使用異步日志記錄是當您使用日志記錄審計目的。 在這種情況下，記錄錯誤是您的應用程序需要了解和處理的問題。 我相信大多數應用程序都是不同的，因為它們不太在乎日志錯誤。 大多數應用程序都不想在發生日志記錄異常時停止，實際上，他們甚至不想知道它。 默認情況下，Log4j-2.0中的附加程序將抑制異常，因此應用程序無需嘗試/捕獲每個日志語句。 如果這是您的用法，那么使用異步記錄器將不會造成任何損失，因此您只能獲得收益，即性能得到改善。”

“我應該提到的一個不錯的小細節是，異步記錄器和異步追加器都修復了一些在Log4j-1.x中一直困擾我的東西，即它們將在記錄隊列中的最后一個事件后刷新緩沖區 。 對于Log4j-1.x，如果使用緩沖的I / O，則通常看不到最后幾個日志事件，因為它們仍然卡在內存緩沖區中。 您唯一的選擇是將InstantFlush設置為true，這將在每個單個日志事件上強制使用磁盤I / O，并會影響性能。 使用Log4j-2.0中的Async Loggers和Appenders，您的日志語句都被刷新到磁盤上，因此它們始終可見，但這是以非常有效的方式發生的。”

登錄使用Log4js AsyncLoggers冒險嗎？

但是考慮到Log4j-1存在嚴重的線程問題，并且現代世界一直在使用云計算和群集來擴展其應用程序， 異步日志記錄不是某種額外的風險嗎？ 還是安全？ 我知道我的問題聽起來像是決策者而不是開發人員的問題。 但是整個LMAX對我來說還是那么新，并且由于我保留了舊的而且非常丑陋的Log4j 1代碼，因此我只需要詢問一下。

雷姆科：“那里有很多問題。 首先，從并發角度看，Log4j-2是否比Log4j-1.x安全？ 我相信是這樣。 Log4j-2團隊付出了巨大的努力來支持多線程應用程序，并且異步記錄器只是該項目的一個非常新的且相對較小的功能。 與Log4j-1.x相比，Log4j-2使用的粒度鎖定更多，并且在結構上更簡單，這將導致更少的問題，并且出現的任何問題都將更易于解決。”

“另一方面，Log4j-2仍處于測試階段，并且仍在積極開發中，盡管最近我認為大多數精力都花在了修復問題和捆綁松散的末端上，而不是添加新功能。 我相信它足夠穩定以供生產使用。 如果出于性能或其他原因考慮使用Log4j-2，我建議您進行盡職調查和測試，就像在項目中采用任何其他第三方庫之前一樣。”

（旁注：很快就會看到Log4j2的穩定版本，很可能是2013年秋天）。

對我來說聽起來不錯。 是的，盡管我個人沒有在Log4j 2存儲庫中編寫代碼，但從我對項目的觀察中我可以完全同意這一點。

“我看到的另一個問題是： 異步日志記錄比同步日志記錄有風險嗎？ 我不這么認為，實際上，如果您的應用程序是多線程的，則情況可能恰恰相反：一旦將日志事件移交給執行I / O的使用者線程，則只有一個線程在處理布局，附加程序以及所有其他與日志記錄相關的組件。 因此，在移交之后，您將成為單線程的，并且您無需再擔心任何線程問題，例如死鎖和活動性等。”

“您可以采取進一步的措施，并使用干擾器進行所有I / O或與外部系統的通信，使您的業務邏輯完全是單線程的。 沒有鎖爭用的單線程業務邏輯可以非常快。 LMAX的結果（600萬筆事務/秒，延遲少于10毫秒）是不言而喻的。”

閱讀雷姆科的信息，我學到了三件事。

• 首先，我必須學習有關Java性能的更多信息。
• 其次，我絕對想讓我的應用程序使用Log4j2。作為第一步，我將在經常使用的Struts 2應用程序中啟用它。
• 第三，使用LMAX Disruptor的Web應用程序框架可能會讓我們震驚。

我要非常感謝您，并向Remko Popma表示一個擁抱，感謝他們回答我的問題并與我一起撰寫此博客文章。 所有錯誤都是我自己的。

雷姆波波瑪

二十年前，雷姆科（Remko）前往日本，以提高圍棋比賽的水平。 不知何故他再也沒有回來。 Remko開始為日本軟件公司進行軟件開發，短暫地擔任自由開發人員，與日本合作伙伴一起經營了一家軟件公司，現在正領導瑞穗證券IT的算法交易開發。 他與妻子Tomoe和兒子Tobias一起住在東京。

參考： Log4j 2： PHP和Java Entwickler博客上的JCG合作伙伴 Christian Grobmeier的性能接近瘋狂 。

翻譯自: https://www.javacodegeeks.com/2013/07/log4j-2-performance-close-to-insane.html

log4j性能 slf4j

總結

以上是生活随笔為你收集整理的log4j性能 slf4j_Log4j 2：性能接近疯狂的全部內容，希望文章能夠幫你解決所遇到的問題。

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