AsyncAppender, asynchronous logging
working principle:
When the Logging Event enters the AsyncAppender, the AsyncAppender will call the appender method. In the append method, before filling the event into the Buffer (the data structure selected here is BlockingQueue), it will first determine the capacity of the current buffer and whether the discard log feature is enabled. When the capacity is not as good as the production capacity, the AsyncAppender will exceed the Logging Event level of the buffer capacity and discard it. AsyncAppender has a thread class Worker, which is a simple thread class and is the background thread of AsyncAppender. The work to be done is to take the event from the buffer and hand it over to the corresponding appender for subsequent log push.
As can be seen from the above description, AsyncAppender does not process logs, but just buffers logs into a BlockingQueue, and creates a worker thread internally to obtain logs from the head of the queue, and then cyclically records the obtained logs to the attached other The appender goes up, so as to achieve the effect of not blocking the main thread. So AsynAppender just acts as an event forwarder and must reference another appender to do things.
When using AsyncAppender, there are some options to pay attention to. Since BlockingQueue is used to cache logs, the queue is full. As mentioned in the above principle, in this case, AsyncAppender will do some processing: by default, if the queue is 80% full, AsyncAppender will discard TRACE, DEBUG and INFO level events, from this point you can see It turns out that this strategy has a staggering performance impact on the cost of event loss. In addition, some other option information will also have an impact on performance. The following is a list of commonly used attribute configuration information:
| property name | Types of | describe |
| queueSize | int | The maximum capacity of the BlockingQueue, by default, the size is 256. |
| discardingThreshold | int | By default, when the BlockingQueue still has 20% capacity, it will discard TRACE, DEBUG and INFO level events, and only keep WARN and ERROR level events. To keep all events, set this value to 0. |
| includeCallerData | boolean | Extracting caller data is quite expensive. To improve performance, by default, when the event is added to the queue, the caller data associated with the event is not fetched. By default, only "cheap" data, such as thread name. |
By default, the event queue is configured with a maximum capacity of 256 events. If the queue fills up, the application thread is blocked from recording new events until the worker thread has a chance to forward one or more events. Therefore, the queue depth needs to be tested according to the business scenario, and corresponding changes should be made to achieve better performance.
eg
<appender name="FILE" class= "ch.qos.logback.core.rolling.RollingFileAppender">
<!-- Roll back by day, if you need to roll back by hour, set it to {yyyy-MM-dd_HH} -->
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>/opt/log/test.%d{yyyy-MM-dd}.log</fileNamePattern>
<!-- If you roll back by day, the maximum storage time is 1 day, and all items before 1 day will be cleaned up -->
<maxHistory>30</maxHistory>
<!-- 日志输出格式 -->
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%msg%n</Pattern>
</layout>
</appender>
<!-- 异步输出 -->
<appender name ="ASYNC" class= "ch.qos.logback.classic.AsyncAppender">
<!-- 不丢失日志.默认的,如果队列的80%已满,则会丢弃TRACT、DEBUG、INFO级别的日志 -->
<discardingThreshold >0</discardingThreshold>
<!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
<queueSize>512</queueSize>
<!-- 添加附加的appender,最多只能添加一个 -->
<appender-ref ref ="FILE"/>
</appender>
<root level ="trace">
<appender-ref ref ="ASYNC"/>
</root>
摘自
http://blog.csdn.net/zhuyucheng123/article/details/21524549