Logback 配置文件这么写,TPS提高10倍

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Logback 配置文件这么写,TPS提高10倍

通过阅读本篇文章将了解到

 

1.日志输出到文件并根据LEVEL级别将日志分类保存到不同文件

2.通过异步输出日志减少磁盘IO提高性能

3.异步输出日志的原理

 

配置文件logback-spring.xml

 

SpringBoot工程自带logback和slf4j的依赖,所以重点放在编写配置文件上,需要引入什么依赖,日志依赖冲突统统都不需要我们管了。

 

logback框架会默认加载classpath下命名为logback-spring或logback的配置文件。

 

将所有日志都存储在一个文件中文件大小也随着应用的运行越来越大并且不好排查问题,正确的做法应该是将error日志和其他日志分开,并且不同级别的日志根据时间段进行记录存储。

 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <property resource="logback.properties"/>
    <appender name="CONSOLE-LOG" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <pattern>[%d{yyyy-MM-dd' 'HH:mm:ss.sss}] [%C] [%t] [%L] [%-5p] %m%n</pattern>
        </layout>
    </appender>
    
    <appender name="INFO-LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>DENY</onMatch>
            <onMismatch>ACCEPT</onMismatch>
        </filter>
        <encoder>
            <pattern>[%d{yyyy-MM-dd' 'HH:mm:ss.sss}] [%C] [%t] [%L] [%-5p] %m%n</pattern>
        </encoder>
 
        
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            
            <fileNamePattern>${LOG_INFO_HOME}//%d.log</fileNamePattern>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
    </appender>
    <appender name="ERROR-LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>ERROR</level>
        </filter>
        <encoder>
            <pattern>[%d{yyyy-MM-dd' 'HH:mm:ss.sss}] [%C] [%t] [%L] [%-5p] %m%n</pattern>
        </encoder>
        
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            
            <fileNamePattern>${LOG_ERROR_HOME}//%d.log</fileNamePattern>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
    </appender>
 
    <root level="info">
        <appender-ref ref="CONSOLE-LOG" />
        <appender-ref ref="INFO-LOG" />
        <appender-ref ref="ERROR-LOG" />
    </root>
</configuration>

 

部分标签说明

 

  • <appender-ref>标签,添加append
  • name属性指定appender命名
  • class属性指定输出策略,通常有两种,控制台输出和文件输出,文件输出就是将日志进行一个持久化。
  • ConsoleAppender将日志输出到控制台
  • <level>标签指定过滤的类型
  • <root>标签,必填标签,用来指定最基础的日志输出级别
  • <append>标签,通过使用该标签指定日志的收集策略
  • <filter>标签,通过使用该标签指定过滤策略
  • <encoder>标签,使用该标签下的<pattern>标签指定日志输出格式
  • <rollingPolicy>标签指定收集策略,比如基于时间进行收集
  •    <fileNamePattern>标签指定生成日志保存地址 通过这样配置已经实现了分类分天手机日志的目标了

 

 

logback 高级特性异步输出日志

 

之前的日志配置方式是基于同步的,每次日志输出到文件都会进行一次磁盘IO。采用异步写日志的方式而不让此次写日志发生磁盘IO,阻塞线程从而造成不必要的性能损耗。异步输出日志的方式很简单,添加一个基于异步写日志的appender,并指向原先配置的appender即可

 

    <appender name="ASYNC-INFO" class="ch.qos.logback.classic.AsyncAppender">
        
        <discardingThreshold>0</discardingThreshold>
        
        <queueSize>256</queueSize>
        
        <appender-ref ref="INFO-LOG"/>
    </appender>
 
    <appender name="ASYNC-ERROR" class="ch.qos.logback.classic.AsyncAppender">
        
        <discardingThreshold>0</discardingThreshold>
        
        <queueSize>256</queueSize>
        
        <appender-ref ref="ERROR-LOG"/>
    </appender>

 

异步输出日志性能测试

 

既然能提高性能的话,必须进行一次测试比对,同步和异步输出日志性能到底能提升多少倍?

 

服务器硬件

 

  • CPU 六核
  • 内存 8G

 

测试工具

 

Apache Jmeter

 

同步输出日志

 

  • 线程数:100
  • Ramp-Up Loop(可以理解为启动线程所用时间) :0 可以理解为100个线程同时启用
  • 测试结果

 

 

 

重点关注指标Throughput【TPS】吞吐量:

 

系统在单位时间内处理请求的数量,在同步输出日志中TPS为44.2/sec

异步输出日志

 

  • 线程数 100
  • Ramp-Up Loop:0
  • 测试结果

 

 

 

TPS为497.5/sec,性能提升了10多倍!!!

 

异步日志输出原理

 

从logback框架下的Logger.info方法开始追踪。一路的方法调用路径如下图所示:

 

 

 

异步输出日志中最关键的就是配置文件中ch.qos.logback.classic包下AsyncAppenderBase类中的append方法,查看该方法的源码:

 

 

protected void append(E eventObject) {
        if(!this.isQueueBelowDiscardingThreshold() || !this.isDiscardable(eventObject)) {
            this.preprocess(eventObject);
            this.put(eventObject);
        }
    }

 

通过队列情况判断是否需要丢弃日志,不丢弃的话将它放到阻塞队列中,通过查看代码,这个阻塞队列为ArrayBlockingQueueu,默认大小为256,可以通过配置文件进行修改。

 

Logger.info(...)到append(...)就结束了,只做了将日志塞入到阻塞队列的事,然后继续执行Logger.info(...)下面的语句了。

 

在AsyncAppenderBase类中定义了一个Worker线程,run方法中的关键部分代码如下:

 

E e = parent.blockingQueue.take();
aai.appendLoopOnAppenders(e);

 

从阻塞队列中取出一个日志,并调用AppenderAttachableImpl类中的appendLoopOnAppenders方法维护一个Append列表。Worker线程中调用方法过程主要如下图:

 

 

最主要的两个方法就是encode和write方法,前一个法方会根据配置文件中encode指定的方式转化为字节码,后一个方法将转化成的字节码写入到文件中去。

 

所以写文件是通过新起一个线程去完成的,主线程将日志扔到阻塞队列中,然后又去做其他事情了。

 

 

 

最后附项目完整代码:https://github.com/TiantianUpup/springboot-log

相关文章
|
1月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
218 3
|
消息中间件 JavaScript 小程序
SpringBoot 实现 MySQL 百万级数据量导出并避免 OOM 的解决方案
SpringBoot 实现 MySQL 百万级数据量导出并避免 OOM 的解决方案
|
2月前
|
存储 数据采集 Java
Spring Boot 3 实现GZIP压缩优化:显著减少接口流量消耗!
在Web开发过程中,随着应用规模的扩大和用户量的增长,接口流量的消耗成为了一个不容忽视的问题。为了提升应用的性能和用户体验,减少带宽占用,数据压缩成为了一个重要的优化手段。在Spring Boot 3中,通过集成GZIP压缩技术,我们可以显著减少接口流量的消耗,从而优化应用的性能。本文将详细介绍如何在Spring Boot 3中实现GZIP压缩优化。
305 6
|
5月前
|
存储 Java 测试技术
Logback配置文件这么写,TPS提高10倍
Logback配置文件这么写,TPS提高10倍
69 1
|
Java 关系型数据库 MySQL
SpringBoot 实现 MySQL 百万级数据量导出并避免 OOM 的解决方案!
SpringBoot 实现 MySQL 百万级数据量导出并避免 OOM 的解决方案!
579 0
|
6月前
|
缓存 监控 关系型数据库
2核4G 配置的MySQL 5.6如何调优为最佳qps,tps
要提高具有2核4G配置的MySQL 5.6的QPS(每秒查询率)和TPS(每秒事务数),可以通过以下方法进行调优: 1. 优化配置文件(my.cnf): 在MySQL的配置文件中,可以调整以下参数以提高性能: ``` [mysqld] innodb_buffer_pool_size = 1.5G # 设置InnoDB缓冲池大小,推荐值为服务器总内存的50%-80% max_connections = 500 # 设置最大连接数,根据实际需求进行调整 query_cache_size = 128M # 设置查询缓存大小,推荐值
530 2
|
并行计算 前端开发 JavaScript
【修正版】QPS、TPS、RT、并发数、吞吐量理解和性能优化深入思考
在了解qps、tps、rt、并发数之前,首先我们应该明确一个系统的吞吐量到底代表什么含义,一般来说,系统吞吐量指的是系统的抗压、负载能力,代表一个系统每秒钟能承受的最大用户访问量。
4750 1
【修正版】QPS、TPS、RT、并发数、吞吐量理解和性能优化深入思考
|
Java 应用服务中间件 测试技术
Tomcat压力测试tps性能下降问题
Tomcat压力测试tps性能下降问题
公司项目升级到Spring 5.3.x之后,GC次数急剧增加,我TM人傻了
最近我们的项目升级到了 Spring Boot 2.4.6 + Spring Cloud 2020.0.x,但是升级后,我们发现 YoungGC 明显增高,分配对象速率明显增高,但是晋升的对象并没有增多,证明都是新创建的对象并且没过多久就可以被回收。我们来看其中一个进程的监控,这时候的 http 请求速率大概在 100 左右: