Log4j 2 性能测试
性能
除了基本的功能需求之外，选择一个日志记录库的重要的非功能需求包括稳定性和效率。
当前页面比较了几种日志框架的性能（JUl,logback,log 4j 1.2,log4j 2.6）,并且记录了一些log 4j 2基本功能的性能权衡。
性能测试
执行性能意味着对于不同的人可能是不同的事情。在这个环境中，常用的术语一般是吞吐量和延迟程度。吞吐量是一个容量单位并且可以被表达为一个数量级：定义为在过去一段确定的时间内，多少日志被记录。而响应延迟是记录一个信息需要多久。延迟不能使用一个简单的数字来表达，因为每个度量衡都有它自己的响应时间。我们一般关注的是异常值：异常值是多少个和异常值是多大。
当评估一个日志框架的性能指标的时候，这有几个使用的问题：
1.什么是它的【峰值吞吐量】？
许多在对外界做响应的系统需要记录在长时间系统平稳后的突发事件的日志。这个数值是过去短时间内被测量出来的最大吞吐量，同时也可以了解当前系统在突发事件下的日志记录情况。但是对于需要以一定稳定的高速率来记录日志的系统比如批处理系统，这种方式可能就看起来不那么有效了。因为这种情况下不会有突发和稳定的切换。无法测量出峰值。
2.什么是【最大持续吞吐量】？
这个值代表过去一段时间内的吞吐平均值。这个是测量一个日志记录库的上限的有用指标。对于一个接受外界反馈的程序系统是建议按照这个速度进行记录日志的，因为在这种系统负载下，系统将会可能比较紧张和出现大量的响应时间的尖刺尖峰。
3.在各种各样的负载下它们的【响应时间】如何？
对于一个联系外界并反馈的系统来说，及时的响应是一个很重要的问题。【响应时间】是记录信息的总时长，同时也是【服务时间】加上【等待时间】的总时间。【服务时间】是记录日志的总时间。随着工作负载的升高，【服务时间】也会有一点不一样:如果有X个工作那么他就会需要X个的时间。【等待时间】是指请求在队列中等待到被处理的时间。随着工作负载量的增加，【等待时间】也会比服务时间大几倍。
题外话：为什么要关注响应延迟时间？
实际上，被测量和作为延迟来讲的一般都是选取【服务时间】,并且忽略了【服务时间】的峰值对于某些子事件来讲会增加【等待时间】。这样子出来的结果可能比用户体验过的要更为好一点，因为忽略了等待时间。
上面图里展示了【响应时间】比起【服务时间】长的多。所以延迟也高得多。这个图显示的是，在100000 条/s的消息的负载下，【响应时间】和【服务时间】的对比。在超过2400万测试中，仅仅有50条消息的消息超过250微秒，这个量小于0.001%。如果在只有【服务时间】的测试中这几乎是看不到的。然而，在峰值之后，由于负载的不同，【服务时间】可能需要一点时间去赶上【响应时间】。因为正常情况下【响应时间】=【服务时间】+【等待时间】，所以两条曲线如果没有峰值的话几乎趋势一样的。