7. Nested Diagnostic Contexts
在现实世界中的系统经常不得不同时处理多个客户端请求。在这样的一个典型的多线程的系统中,不同的线程将处理不同的客户端。Logging特别能够适应这种复杂的分布式的应用程序的调试和跟踪。一个常见的区分每个客户端所输出的Logging的方法是为每个客户端实例化一个新的独立的Logger。这导致Logger的大量产生,管理的成本也超过了logging本身。
唯一标识每个log请求是一个轻量级的技术。Neil Harrison 在名为“Patterns for Logging Diagnostic Messages”的书中描述了这个方法in Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, and F. Buschmann (Addison-Wesley, 1997).
为了唯一标识每个请求,用户把上下文信息推入NDC(Nested Diagnostic Context)中。
NDC类示例如下:
public class NDC {
// Used when printing the diagnostic
public static String get();
// Remove the top of the context from the NDC.
public static String pop();
// Add diagnostic context for the current thread.
public static void push(String message);
// Remove the diagnostic context for this thread.
public static void remove();
}
NDC如同一个堆栈样管理每个线程。注意所有the org.apache.log4j.NDC 类的方法都是静态的。假设NDC输出被开启,每次一个log 请求被生成时,适当的log4j组件为将要输出log的线程包含完整的NDC堆栈。这是在没有用户的干预的情况下做到的,用户只负责在NDC中定位正确的信息,通过在代码中正确位置插入很少的push和pop方法就行了。相反的,在代码中per-client实现方法有着很大变化。
为了演示这个点,让我们以一个发送内容到匿名客户端的servlet为例。这个servlet可以在开始执行每个其他代码前的初始化时建立NDC。上下文信息可以是客户主机的名字和其他的请求中固有的信息。
典型的信息包括cookies。因此,即使servlet同时为多个客户同时提供服务,log 被同样的代码初始化,例如属于同一个logger,依然可以被区别,因为每个客户请求将有不同的NDC堆栈。与之相比,Contrast this with the complexity of passing a freshly instantiated logger to all code exercised during the client's request。
不过,一些诡异的程序,例如虚拟主机的web server记录日志,不是一般的依靠虚拟主机的上下文,还要依靠软件的组件发出请求。近来log4j的发布版本支持多层的树形结构。这个增强允许每个虚拟主机可以处理在树型结构中属于它自己的logger。
8. 优化
一个经常引用的依靠于logging的参数是可以计算的花费。这是一个合理的概念,一个适度的应用程序可能产生成千上万个日志请求。许多努力花在测量和调试logging的优化上。Log4j要求快速和弹性:速度最重要,弹性是其次。
用户应该注意随后的优化建议。
1.日志为禁用时,日志的优化。
当日志被彻底的关闭,一个日志请求的花费等于一个方法的调用加上整数的比较时间。
在233mhz的Pentium II 机器上这个花费通常在5-50纳秒之间。
然而,方法调用包括参数构建的隐藏花费。
例如,对于logger cat,
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
引起了构建信息参数的花费,例如,转化整数i和entry[i]到一个string,并且连接中间字符串,不管信息是否被输出。这个参数的构建花费可能是很高,它主要决定于被调用的参数的大小。
避免参数构建的花费应如下,
if(logger.isDebugEnabled() {
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}
如果logger的debug被关闭这将不会招致参数构建的花费。另一方面,如果logger是debug的话,它将产生两次判断 logger是否能用的花费。一次是在debugenabled,一次是debug。这是无关紧要的,因为判断日志的能用 只占日志实际花费时间的约1%。
在Log4j里,日志请求在Logger 类的实例里。Logger 是一个类,而不是一个接口。这大量的减少了在方法调用上的弹性化的花费。
当然用户采用预处理或编译时间技术去编译出所有的日志声明。这将导致完美的执行成效。然而因为二进制应用程序不包括任何的日志声明的结果,日志不可能对那个二进制程序开启。以我的观点,以这种较大的代价来换取较小的性能优化是不值得的。
2。当日志状态为启用时,日志的优化。
这是本质上的优化logger的层次。当日志状态为开,Log4j依然需要比较请求的级别与logger的级别。然而, logger可能没有被安排一个级别;它们将从它们的father继承。这样,在继承之前,logger可能需要搜索它的ancestor。
这里有一个认真的努力使层次的搜索尽可能的快。例如,子logger仅仅连接到它的存在的father logger。
在先前展示的BasicConfigurator 例子中,名为com.foo.bar 的logger是连接到跟根logger,因此绕过 了不存在的logger com和com.foo。这将显著的改善执行的速度,特别是解析logger的层结构时。
典型的层次结构的解析的花费是logger彻底关闭时的三倍。
3.日志信息的输出时,日志的优化。
这是主要花费在日志输出的格式化和发送它到它的输出源上。这里我们再一次的付出努力以使格式化执行的尽可能快。同appender一样。实际上典型的花费大约是100-300毫秒。
详情看org.apache.log4.performance.Logging。
虽然Log4j有许多特点,但是它的第一个设计目标还是速度。一些Log4j的组件已经被重写过很多次以改善性能。不过,投稿者经常提出了新的优化。你应该满意的知道,以SimpleLayout的配置执行测试已经展示了Log4j的输出同System.out.println一样快。
9. 总结
Log4j是一个用java写成的流行的日志包。一个它与众不同的特点是在logger中的继承的概念。用logger的继承可以以任意的间隔控制日志的状态输出。这个减少了体积和最小化日志的代价。
易管理性是Log4j API的优点之一。只要日志定义被加入到代码中,它们就可以用配置文件来控制。它们可以有选择的被禁用,并且发送到不同的多个输出源上,以用户选择好的格式。
Log4j的包被设计成,不需花费沉重的执行代价就可以保留它们在产品中。