Logback框架中AsyncAppender的配置和性能

Thi*_*ker 5 java logback spring-boot

嗨目前我正在研究logback日志框架.我遇到了Async Appenders,它使用阻塞队列来记录消息,使得所有线程都将阻塞队列中的消息排入队列,async appender的工作线程负责将消息从队列记录到某个目的地,这可能是由appender决定的.文件,数据库,套接字等

我可以看到响应时间内的性能提升,因为主线程不执行I/O它只推送队列中的消息,而后台工作线程中异步appender检索这些消息并将它们附加到日志文件中.

我的理解是对的吗?我读了几个与async appender相关的配置属性,如队列大小,maxFlushTime,neverBlock,discardingThreshold和includeCallerData.

我应该如何使用这些属性来提高日志记录的性能我的异步Appender的当前配置如下.

<appender name="ASYNC500" class="ch.qos.logback.classic.AsyncAppender">
   <appender-ref ref="fileAppender"/>
   <queueSize>500</queueSize>
  <maxFlushTime>1000</maxFlushTime>
</appender>
Run Code Online (Sandbox Code Playgroud)

有人可以建议我进行一些调整,以获得性能.?哪个更好的普通appender或Async Appender?

gly*_*ing 11

首先回答第二个问题......

哪个更好的普通appender或Async Appender?

这里的答案是:它取决于.为了澄清这里使用的优点和缺点AsyncAppender:

  • 优点:

    • Logger.debug|info|warn|error对于异步记录器而言,较低的日志事件延迟(即任何给定调用完成所花费的时间) 将低于同步记录器.
    • 吞吐量更高.这对于具有突发日志的应用程序特别有用,即偶尔的大型日志事件突发.异步日志记录 - 特别是如果配置的队列大小足以满足这些峰值 - 将防止在面对这些峰值时可能出现的日志调用缓慢.
  • 缺点:

    • 如果您的应用程序已经受CPU限制,那么启动另一个线程来处理异步日志事件将不会带来太多好处
    • 如果您的应用程序比async appender内部的appender更快地发出日志事件,那么异步appender将开始排队日志事件,如果这种情况继续,那么您的应用程序可能会面临缓慢排放和丢弃事件之间的决定
    • 在日志中从异步记录器写回发送程序时传播错误比从同步记录器传播错误要复杂得多

根据您的使用情况,您可能会发现其中一些优点和缺点比其他优先级更重要.AsyncAppender如果你有明确的需要,我建议你不要只使用一个.

回到你的第一个问题......

有人可以建议我进行一些调整以获得性能吗?

这就是我先回答第二个问题的原因.在不知道应用程序的细节和它的运行时配置(主机上的内存和CPU,要包装的appender的类型AsyncAppender以及丢弃日志事件的容忍度)的情况下,不可能说出如何配置它.但是,你会知道关于你自己的应用程序的所有这些事情,所以考虑到这些知识,我建议在决定是否以及如何配置时考虑以下内容AsyncAppender:

  • queueSize:这越大,应用程序线程上的阻塞就越少.如果异步appender的队列填满,则将阻止应用程序线程记录新事件,直到工作线程有机会从队列中删除项目.因此,queueSize如果应用程序倾向于产生足够的近并发日志事件来填充队列,则增加吞吐量将提高吞吐量.但请记住,只有当应用程序能够淹没现有队列大小并且以堆使用为代价时,吞吐量的这种增加才是相关的.
  • includeCallerData:从日志事件中读取调用者提供的数据可能很昂贵,您通常会发现将其设置为false提高性能,除非您在日志事件中有一些定制的调用者提供的数据,否则您实际上不会丢失任何数据
  • neverBlock:将此设置为true将阻止应用程序线程上的任何阻塞,但如果async appender的内部缓冲区填满,则会以丢失日志事件为代价.

所以......

  • 如果最大化吞吐量对您而言至关重要,并且您不关心丢失某些事件,那么请使用 neverBlock=true

  • 如果最大化吞吐量对您很重要并且您的堆中有足够的空间并且您不能容忍丢失日志事件,那么请使用: queueSize=_some_number_which exceeds_ the_maximum_queue_size_observed_in_testing_plus_25_percent_

这里有更多细节: