2013-08-28 20 views
1

我正在使用java進行交易應用程序(一次處理數百萬個數據),它是廣泛多線程的。應用程序將消息記錄在日誌文件中。目前,這種日誌記錄的性能很低,並且花費了大量的CPU時間。在多線程應用程序中登錄

我想重新實施它。我搜索了一下,發現LinkedBlockingQueue作爲一個選項。由於它的固定大小,不能使用arrayBlockingQueue

此外,像log4j這樣的框架也聽起來不錯,因爲它們是線程安全的。但我懷疑log4j是否是多線程應用程序的一個很好的性能選擇。

什麼可能是我應該選擇在我的多線程應用程序中進行日誌記錄的最佳數據結構/框架?

+0

使用經過驗證的記錄框架:它比任何你可以在合理的時間內設計的效率更高...... – assylias

回答

1

如果我是你,我會首先嚐試slf4j。這只是一個外觀,但您可以使用log4j2作爲實現。 如果的速度很慢,那麼在這之後就可以很容易地嘗試JUL和其他日誌框架。這只是一個配置和類路徑的變化。

如果您嘗試的每個記錄器都很慢,您可能需要查看http://zeromq.org/。但我認爲記錄器應該沒問題。我通常不會聽到人們抱怨他們的日誌框架如何減慢他們的應用程序,除非他們打印出過多的調試語句。

3

對於高性能的日誌記錄,我用Java Chronicle(主要是因爲我寫的),它可以支持100K - 每秒1M短信在GC少辦法。您可以通過用鎖包裝它來使其線程安全。它不如其他記錄儀那麼簡單,因爲它是較低的水平,但它是我知道的最快的。

如果使用二進制日誌記錄,它可以支持每秒超過10M的消息/事件。我正在開發一個Java Chronicle 2.0,速度提高了3倍。

無界隊列通常是一件壞事。如果綁定隊列不是您的選項,很可能您有設計問題。如果你真的需要一個無限的,Java編年史可能是你唯一的選擇,因爲沒有其他圖書館真正以高性能的方式支持這一點。 Log4j 2.0使用有界的環形緩衝區。

+0

嗨,彼得,你有一個例子,可以用編年史寫短信嗎?我可以找到的每個示例都是用於編寫二進制數據。 – CaptainHastings

+0

@CaptainHastings IndexedChronicleTest.testParseLines()和TestManyUpdatesMain。看看ByteStringAppender。 –

+1

非常感謝和BTW Chronicle是血腥真棒! – CaptainHastings

1

甚至不要考慮去與log4j。請。去的logback

的logback的目的是作爲繼任者的熱門log4j的項目,拿起其中的log4j離開了。 Logback的體系結構足夠通用,適用於不同的環境。目前,logback分爲三個模塊,logback-core,logback-classic和logback-access。

Logback有你已經開箱即用的appender。被稱爲AsyncAppender

AsyncAppender日誌ILoggingEvents異步。它只是作爲一個事件調度員,因此必須引用另一個appender來做任何有用的事情。

如果默認值爲80%,AsyncAppender緩衝BlockingQueue中的事件。由AsyncAppender創建的工作線程從隊列的頭部獲取事件,並將其分派到連接到AsyncAppender的單個appender。請注意,默認情況下,如果AsyncAppender的隊列已滿80%,它將刪除級別爲TRACE,DEBUG和INFO的事件。該策略以事件損失爲代價對性能產生了驚人的有利影響。