Open Source .NET Development [Electronic resources] نسخه متنی

Performance and Scalability

Log4Net is very performance-driven. While Log4Net has many features and goals, the top priority is performance. The bulk of the added overhead of Log4Net is actually having the Appender write the message to the target. Here are some tips to help Log4Net perform at an optimal Level.

GAC

Does inserting Log4Net into the Global Assembly Cache (GAC) gain any performance? In .NET, there is some overhead involved with the Just-In-Time (JIT) compiler. Pre-Jitting the assembly into a native image helps speed up the startup process, but it can also prevent the runtime from making some runtime optimizations. Ngen.exe is the tool to pre-jit an assembly that uses the GAC file structure to store the output of ngen but does not require your assembly to be in the GAC. By putting Log4Net into the GAC, you allow for shared memory code pages during execution. If a large number of applications will be using the assembly, you will gain some memory. Microsoft recommends using private deployment unless you really have a good reason to use the GAC. Depending on the number of applications that use Log4Net, you may or may not see performance improvement by putting Log4Net in the GAC. The disadvantage is that you can no longer do XCopy deployment; however, you do gain side-by-side execution to allow multiple versions of Log4Net to be on one system without interference.

Parameter Construction

Parameter construction, while not extremely costly by itself, can add up when used too often. Listing 8.13 shows how to avoid parameter construction.

Listing 8.13. Avoiding Parameter Construction

While it is not best practice to always log the exception this way, the point of Listing 8.13 is that while the Logger.Debug class will automatically check the Level for you, it will happen after the string has already been constructed, and that could be costly. By checking the Level yourself while adding code, you will improve the performance of your logging.

Hierarchy

Logger hierarchy walking for every LoggingEvent message is expensive. Every message is passed up through the entire hierarchy and sent to each Logger's Appender. You can gain significant performance by turning off the walking of the hierarchy and logging directly to the root Logger.

Stack Tracing

The first thing that usually happens with Log4Net is that developers fall in love with it for debugging. Then the developers build their application in Release mode for integration testing and say, "Where did all my line numbers go?"

Table 8.6 on p. 207 showed the different patterns that can be used to capture information like file, method, and line numbers. The following patterns can have significant effect on your application's performance.

%d

%l

%C

%M

%F

%L

Some of these pattern formatters are associated with formatting (like the date pattern), but the big performance problem comes with trying to provide the source file name and line number. In order to achieve this, Log4Net attempts to walk up through the stack and trace the exception. This is done by using the StackTrace and Stackframe classes from the System.Diagnostics namespace, and Log4Net cannot guarantee that the information will be available. This is not the fault of Log4Net because only the Debug builds contain the file information, method name, and line numbers. Even with Debug information, because of security settings, Log4NET may not be able to walk the stack, or because of runtime optimizations, the information may not be deep into the call stack, as you would expect. Thus, turning the Debug flag off for Managed code will not really increase your performance, and leaving them on could be useful. Do keep in mind though that decompilation of the code is much easier if it is shipped with Debug symbols.