?Log4j簡明手冊（3/3）
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
如果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的包被設計成，不需花費沉重的執行代價就可以保留它們在產品中。
posted on 2007-01-03 17:04
???MengChuChen 閱讀(259)
評論(0) 編輯 收藏 所屬分類:
Log4j