You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4php-user@logging.apache.org by Lst Recv <li...@gmail.com> on 2005/06/23 00:15:12 UTC

log4php overhead

A key requirement of loggers is to stay out of the way when not needed
- that is, not to slow things down.  Java's log4j fulfills this
admirably.

Unlike in Java, where the initial overhead is one time only and hence
minimal, PHP's overhead is constantly repeated froms scratch, due to
the fact that each PHP request is in its own little world.  I measured
about 0.15 sec of CPU time (AMD 3000) to
parse the classes and run a logger, even with all the appenders shut
off.  On a busy server, that can add up to be a lot.  Although I'd
much rather use log4php than my current (feeble) logging system, our
boxen can't afford that much overhead *for every request*.

Any ideas?

(yes, I have thought about php accelarator and the like, and plan to
look into it - but the problem is still of general interest)

Re: log4php overhead

Posted by "Marco V." <ma...@apache.org>.
----- Original Message -----
From: "Lst Recv" <li...@gmail.com>
To: <lo...@logging.apache.org>
Sent: Thursday, June 23, 2005 12:15 AM
Subject: log4php overhead


>A key requirement of loggers is to stay out of the way when not needed
> that is, not to slow things down.  Java's log4j fulfills this
> admirably.

>Unlike in Java, where the initial overhead is one time only and hence
>minimal, PHP's overhead is constantly repeated froms scratch, due to
>the fact that each PHP request is in its own little world.  I measured
>about 0.15 sec of CPU time (AMD 3000) to
>parse the classes and run a logger, even with all the appenders shut
>off.  On a busy server, that can add up to be a lot.  Although I'd
>much rather use log4php than my current (feeble) logging system, our
>boxen can't afford that much overhead *for every request*.

Log4php was heavily inspired to log4j and it's design is almost the same.
Every request needs to include several classes and parse the xml or properties configuration.

>Any ideas?

1. serialize the LoggerHierarchy instance in a file (see an example in tests/others ) after parsing the configuration file.

2. create a new configurator class by subclassing LoggerDOMConfigurator (or LoggerPropertyConfigurator). This class should be able
to load a serialized instance and to configure the LoggerHierarchy.

3. create a new configurator class by subclassing LoggerBasicConfigurator and hardcode your configuration in configure() method.

-Marco