关于性能测试时的隐性杀手--日志级别

前端时间，测试人员再做性能测试时，发现TPS 非常地低，一直搞不明白怎么回事。

查看线程堆栈，发现很多线程在 争夺 日志文件。最后发现日志级别为DEBUG，那个汗。。。。

由此，想了一下，对于应用场景，我们怎么设置我们的日志级别？ 比如log4j中，

日志记录器(Logger)是日志处理的核心组件。log4j具有5种正常级别(Level)。 日志记录器(Logger)的可用级别Level (不包括自定义级别 Level)， 以下内容就是摘自log4j API (http://jakarta.apache.org/log4j/docs/api/index.html):

static Level DEBUG

DEBUG Level指出细粒度信息事件对调试应用程序是非常有帮助的。

static Level INFO

INFO level表明 消息在粗粒度级别上突出强调应用程序的运行过程。

static Level WARN

WARN level表明会出现潜在错误的情形。

static Level ERROR

ERROR level指出虽然发生错误事件，但仍然不影响系统的继续运行。

static Level FATAL

FATAL level指出每个严重的错误事件将会导致应用程序的退出。

另外，还有两个可用的特别的日志记录级别: (以下描述来自log4j APIhttp://jakarta.apache.org/log4j/docs/api/index.html):

static Level ALL

ALL Level是最低等级的，用于打开所有日志记录。

static Level OFF

OFF Level是最高等级的，用于关闭所有日志记录。

日志记录器（Logger）的行为是分等级的。如下表所示：

分 为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。Log4j建议只使用四个级别，优先级从高到低分别是 ERROR、WARN、INFO、DEBUG。通过在这里定义的级别，您可以控制到应用程序中相应级别的日志信息的开关。比如在这里定义了INFO级别， 则应用程序中所有DEBUG级别的日志信息将不被打印出来。

以此信息，那怎么在系统中设置日志级别呢？

应该要和软件开发过程结合起来，同时也要注意区分一下，模块调用关系，对外使用还是对内使用。

1.开发过程中

开发阶段，测试阶段（区分功能测试与性能测试），实际部署运行阶段。一般，开发阶段都是开发人员调试内部代码，引入单元测试，如果不对外公开接口调用，一般都是设置为DEBUG。功能测试一般是验证正确性，特别是牵涉到系统间调用，此时，将输入参数，输出参数都调成DEBUG，这样更容易定位问题。同时也要注意区分调用方还是被调用方。调用方如果调用失败，那就应该调整ERROR 级别，特别是数据库，等底层系统。

性能测试，最好使用与实际运行环境设置一致。而实际部署运行阶段，最好也是区分，试运行一段时间，与最终常态化运行阶段。毕竟实际环境都是有所差异。试运行DEBUG 一段时间，监控日志，及时发现问题，调整。最后设置为INFO。

2.系统内还是系统间

内部系统基本上使用开发过程中的日志对应级别。而如果牵涉系统间调用，由于理不清道不明的道理。建议都在输入输出参数，设为DEBUG模式。特别是与第三方现金合作，，，，

最后说明一点的是，在使用log4j,common-log这样的log框架时，发现很多代码中这样写 
if   (log.isDebugEnabled ())   { 
          log.debug( "xxxx "); 
}

你可能会问我很奇怪，为什么要与log.isDebugEnabled ()？既然log.debug()在没有指定输出级别为DEBUG时不会有输出，为什么还要在前面加一个isDebugEnabled ()的判断？

原因如下：

当输出级别是debug，即需要进行日志信息输出时，加不加这句if判断，在效率上几乎没有差别；

当输出级别高于debug，即不需要进行日志信息输出时：

①假如debug方法中的参数比较简单时（比如直接就是写好的字符串），加不加这句if判断，在效率上也几乎没有什么差别；

②假如debug方法中的参数比较复杂时（比如还要使用别的函数进行计算、或者还要进行字符串的拼接等等），在前面就加上这句if判断，会让效率提高（否则，开始大动干戈做了很多事情（比如字符串的拼接），后来才发现不需要进行输出日志信息）

到此，你可能会问，为什么有这样的效率问题，这个就要了解实参，形参，传递，特别是线程堆栈的问题了。

除了大家都清楚的原因以外，我想还有一点就是JVM的激进优化掉，这段代码呢。

https://wikis.oracle.com/display/HotSpotInternals/PerformanceTacticIndex