hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pfingstl Gernot" <gernot.pfing...@stmk.gv.at>
Subject AW: Logging
Date Thu, 30 Dec 2004 10:32:25 GMT
Hi Ortwin,
you say that you can achieve only 4% performance gain. But you calculate, that logging will
perform. In a production environment logging should be not the normal case. Only fatals, errors
and maybe warnings should be logged. This should be only serveral lines per day, otherwise
there is something wrong in your application. So you will have 10% performace gain.  But only
if you have constant strings. In httpclient-3.0-beta1 there are also dynamic log strings!If
you change the log statement in Test.java to "log.debug("a constant string"+i);" (to have
varying strings - in the most cases you only can catch errors in a production environment,
if you have more information than static string) the result is very different (log4j):
	unguarded: 6229ms
	guarded: 511ms
	Difference: -5718ms, -0.9179643602504415

	unguarded: 6138ms
	guarded: 511ms
	Difference: -5627ms, -0.9167481264255458

	unguarded: 7691ms
	guarded: 741ms
	Difference: -6950ms, -0.9036536211155897


Times with jdk1.4 logger:
	unguarded: 297820ms
	guarded: 360ms
	Difference: -297460ms, -0.9987912161708414

	unguarded: 271159ms
	guarded: 251ms
	Difference: -270908ms, -0.9990743438351668

	unguarded: 219826ms
	guarded: 241ms
	Difference: -219585ms, -0.9989036783637968

In my opinion a "commons" library should the best possible performance, because the libraries
only a small piece of the application(s) especially in a J2EE environment.
Of course the guarded code looks bad, but I don't know a better solution.

Gernot

-----Ursprüngliche Nachricht-----
Von: Ortwin Glück [mailto:ortwin.glueck@nose.ch]
Gesendet: Montag, 27. Dezember 2004 16:38
An: HttpClient Project
Betreff: Re: Logging




Pfingstl Gernot wrote:
> In httpclient-3.0-beta1 source I saw, that calls to the logging api is always done directly:
> 	LOG.trace("some logging text");
> 
> This may produce a runtime overhead - see http://jakarta.apache.org/commons/logging/guide.html,
chapter "Best Practices (General)", "Code Guards":
> "Code guards are typically used to guard code that only needs to execute in support of
logging, that otherwise introduces undesirable runtime overhead in the general case (logging
disabled). Examples are multiple parameters, or expressions (i.e. string + " more") for parameters.
Use the guard methods of the form log.is<Priority>() to verify that logging should be
performed, before incurring the overhead of the logging method call. Yes, the logging methods
will perform the same check, but only after resolving parameters."
> 
> Do you plan to refactor the above code to:
> 	if(LOG.isTraceEnabled())
> 	{
> 		LOG.trace("some logging text");
> 	}
> 
> Gernot

Gernot,

I quickly hacked up a test case which compares an unguarded call to a 
guarded one. The log string is constant. I used Log4J with WARN level 
and a log.debug call. So no actual log was generated.

I performed a 100 million calls to log.debug. I run the test 3 times in 
a row to give HotSpot a chance to kick in.

unguarded: 6669ms
guarded: 7431ms
Difference: 762ms, 0.1142600089968511

unguarded: 6660ms
guarded: 7411ms
Difference: 751ms, 0.11276276276276276

unguarded: 6600ms
guarded: 7460ms
Difference: 860ms, 0.1303030303030303

So we loose around 10% performance for an unguarded call, if the payload 
is not logged. Logging can take up as much as 40% of the CPU time in 
very extreme cases like our no-host test suite. So best we can achieve 
is a 4% performance gain. Is that worth the trouble?

Ortwin Glück

-- 
  _________________________________________________________________
  NOSE applied intelligence ag

  ortwin glück                      [www]      http://www.nose.ch
  software engineer
  hardturmstrasse 171               [pgp id]           0x81CF3416
  8005 zürich                       [office]      +41-1-277 57 35
  switzerland                       [fax]         +41-1-277 57 12


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message