日志框架，选择Logback Or Log4j2？

写在前面

前段时间写了一篇文章(文章连接：Logback配置文件这么写，TPS提升10倍)，反响还不错，有不少网友也发表了本身的意见：

总结一下就是：

• logback性能测试同步和异步TPS相差不大
• 都9102年了还在用logback

看到网友的意见后又继续去作了一波测试和调研

服务器硬件

• CPU 六核
• 内存 8G

测试工具

• JMeter
• JProfile
• APM(New Relic)

logback日志框架同步和异步测试

以前的测试结果存在如下几点问题：

• 测试样本数过少(即线程数和循环执行次数过少，以前线程数为100，循环1次，样本总数为100)
• 测试次数过少，只进行了一次测试，结果存在偶然性
• 两次测试结果存在污染，样本数量不同

针对以上问题，从新测试中将线程数修改成200，每次测试中循环100次，样本总数为2w，和原来测试的样本数相比扩大200倍，而且重复测试5次。 新的测试结果以下：

新的测试结果代表，使用logback日志框架同步和异步输出日志方式的TPS相差不大。把数据制做成柱形图更直观

可是总以为异步去写日志了，访问api的线程将更快响应客户端，TPS就应该有明显的变化才对。想不通又去网上查阅了一些资料，有反应说经过APM进行性能监控，同步和异步的TPS将会有较大的差异，TPS必定是会有明显变化的(呐喊)，因而用APM去监控JMeter发送的请求(JMeter参数设置为线程数100，Ramp-up Period为0，循环100次)： APM测试结果以下：

APM监控下，在执行的五分钟内异步输出日志TPS平均为378rpm

APM监控下，在执行的五分钟内同步输出日志TPS平均为333rpm 发现TPS同步和异步相比仍是不明显

又一次证实失败 虽然想不明白但后来和网友探讨了下，醍醐灌顶

TPS变化不明显的缘由以下： TPS为每秒处理事务数，每一个事务包括了以下3个过程：

• 用户请求服务器
• 服务器本身的内部处理
• 服务器返回给用户

服务器本身的内部请求包括访问数据库、处理逻辑和打印日志，同步和异步中惟一不一样的就是打印日志的方式。而从测试结果来看，打印日志耗时只占API访问请求的5.3%，因此缩短打印日志耗时不能很明显的提升TPS，由于打印时间和网络请求、业务处理消耗时间能够忽略不计 可是测试结果代表，虽然使用异步输出方式不能明显提升TPS，可是可以减小打印日志的耗时。因此使用logback日志框架仍是推荐使用异步输出方式

推荐使用log4j2而不是logback

log4j2是log4j 1.x 的升级版，参考了logback的一些优秀的设计，而且修复了一些问题，带来了一些重大的提高，在异步方面的性能获得了巨大提高，其除了提供Async Append异步实现外还提供了Async Log异步实现，其中Async Append异步实现方式和logback的异步实现差很少，而Async Log基于LMAX Disruptor库，实现了一个高性能的异步记录器。本次测试中log4j2异步实现是基于Async Log。 JMeter测试参数和以前的logback测试同样，线程数200，循环次数100，重复五轮。而且logj2日志配置文件基本和logback异步配置相同，知足：

• 控制台打印日志
• 分类输出日志
• 按天滚动
• 一样的日志输出格式

测试结果以下：

将TPS制做为柱形图

TPS提高了6倍！！！，而且打印日志的耗时都快到统计不出来了 官方提供的测试报告中，log4j2和logback相比性能提高更明显。附官方测试报告：Asynchronous Loggers for Low-Latency Logging

结论

• 若是使用logback框架，推荐使用异步输出日志方式
• 选择日志框架，推荐使用log4j2
  
  最后附：测试代码

---

原创不易，若转载请标明出处：https://juejin.im/post/5d66a36c518825199701e2ad 做者：何甜甜在吗

另外最近有个小目标，想升到LV3，以为文章不错的点个赞再走嘛

只要人人都献出一点爱，我就能够上LV3