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: David.Egolf@xxxxxxxx
Date: Lun déc 1, 2003 19:39:48 Europe/Paris
To: Emmanuel Cecchet <Emmanuel.Cecchet@xxxxxxxxxxxx>
Cc: college@xxxxxxxxxxxxx, Mathieu.Peltier@xxxxxxxxxxxx, Michael.Giroux@xxxxxxxx, Philippe Merle <Philippe.Merle@xxxxxxx>
Subject: Re: [college] Fwd: [webmaster] New SourceForge project submitted

jotm requirements will drive this high performance logging project.

The need for this project was suggested by the Geronimo project leader, Jeremy Boynes.  The Geronimo personnel had performed preliminary performance measurements and concluded that log4j would not be able to supply the needed performance for recovery logging.  Geronimo developers said that log4j was fine for user application logging.  Jeremy pointed out that each of the resource managers have high performance logging responsibility.  Therefore, a logging facility separate from jotm would potentially be reusable.

I had already identified the logging recovery file as a key element for performance of jotm, and therefore JOnAS, as we implement recovery.  Each transaction requires several I/O's to be performed to a logging facility.  At least one, and usually two, must be flushed before the transaction can proceed.  If these records are written as individual I/O's, then the total system throughput will be tied to a relatively small number of physical disk actuators which can be used for logging.  If performance levels are to be sustained at the > 100K TX/sec level, then block, asynchronous I/O must be provided which allows multiple transactions/threads to participate in each log write.

-- David Egolf

Emmanuel Cecchet <Emmanuel.Cecchet@xxxxxxxxxxxx>

12/01/2003 08:32 AM

        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

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

Reply via email to:

Powered by MHonArc.

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