ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | architecture List | December 2003 Index

<--  Date Index  --> <--  Thread Index  -->

Fwd: [college] Fwd: [webmaster] New SourceForge project submitted

Begin forwarded message:

From: Emmanuel Cecchet <Emmanuel.Cecchet@xxxxxxxxxxxx>
Date: Lun déc 1, 2003  16:32:37 Europe/Paris
To: Michael.Giroux@xxxxxxxx
Cc: Philippe Merle <Philippe.Merle@xxxxxxx>, college@xxxxxxxxxxxxx, Mathieu.Peltier@xxxxxxxxxxxx, David.Egolf@xxxxxxxx Subject: Re: [college] Fwd: [webmaster] New SourceForge project submitted


2. It is too early to say if the MonoLog API can be used or if a new API will be required. We have talked about the benefit to the entire JOnAS project if the MonoLog API can be used, but no conclusions have been made yet. The primary objective of the project is performance. It has been
observed that MonoLog, Log4j, and the Sun J2SE 1.4 logger all have a
performance problem. Some of the performance is due to the flexibility these interfaces provide. The first activity of our project will be to study these logging facilities and understand the performance issue. We will be able to propose an API once we understand the problems that exist
in the current facilities.

We are using Log4J in C-JDBC as a general purpose logging system and we use JDBC for the transaction log (the log is tored in a database). You have to take care when you use logging what kind of information you want to store. The performance is really sensitive to the settings (timestamp precision, package name, function name that needs to keep a stack trace, and so on). Also you need to ensure that you do not use things like:
logger.trace(DEBUG, "some msg"+value+"..."+xxx+"...");
Even if the logging system checks that debugging level is enabled before really logging the message, you have to build the complex string given as a parameter to call the function that will just test if debug is enabled or not. This can result in a dramatic slowdown of your application.
Always ensure that you use :
if (logger.isDebugEnabled())
 logger.trace(DEBUG, "some msg"+value+"..."+xxx+"...");
You will just pay the cost of a boolean check which is nothing and does not cost anything significant.

That said, if you have a lot of information to log, using a file is certainly not the best way. For our transaction log, we have been happy to directly use a database through JDBC to have ACID properties and large throughput. Also if we want the log to be fault tolerant, we just direct the JDBC connection to a C-JDBC cluster.

Could you tell use more on what kind of information you would like to log and which API do you expect from the logging API ? Do you think that native compilation of a Java logging API could solve your performance issues?

PS: By the way, shouldn't we discuss this on the architecture mailing list?

Emmanuel Cecchet
Research Scientist, INRIA Rhône-Alpes
SARDES Project (http://sardes.inrialpes.fr)
phone : +33 (0)4 76 61 52 48 (GMT+1)
fax   : +33 (0)4 76 61 52 52
email : Emmanuel.Cecchet@xxxxxxxxxxxx

Attachment: smime.p7s
Description: Binary data

<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.