I like software - reading, tinkering, designing, coding. I have been doing so for 20 years or so and I would not mind continuing this for foreseeable future. Fortunately for me, this is my profession as well and I have managed to get paid for this for some 14 years now. Although I do not have any strong bias for any business domain, I have been working with some pretty big names in the finance domain and you might get a hint of that from my entries. Partha is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Which one is faster? Log4j or Logback?

07.09.2012
| 15266 views |
  • submit to reddit
Hi, I am back again with my rant about logging as an inherent part of any application design and development. I am a big fan of strong basics, and in my humble opinion logging is one of those often overlooked but basic critical element of any enterprise grade application. I have written about this before here. This article was also reproduced at javalobby at this link. They are not really mandatory read to make sense of the current article, but it might help to give them a cursory look, to set context for this article.

In the first article, I introduced logging as a high benefit, low cost alternative to the omnipresent System.out.println(), that all java folks love so much. I had used log4j in that article. Log4j is a solid framework and delivers on it's promise. In all the years that I have used it, it has never let me down. I can whole heartedly recommend it. However, having said that, there are few alternatives also, which have been around in the market for a while and I am happy to say that at least one of them seem to be challenging log4j in it's own turf. I am talking about Logback.

It is certainly not new kid in the block - and that is one of the reasons I am suggesting you consider this for enterprise grade applications to start with. A quick look at Maven Central suggests that the first version was published way back in 2006. Between 2006 and 8-June2012 - which is when the latest version was pushed to Maven Central, there have been 46 versions. Compare this with log4j. The first version was pushed in Maven Central in 2005 and the last on 26 May 2012, and between these there have been a total of 14 different versions. I do not mean to use this data to compare these two frameworks. The only intent is to assure the reader that Logback have been around long enough and is current enough to be taken seriously.

Being around is one thing and making your mark is different. As far as ambition and intent goes, Logback makes it pretty clear that it intends to be successor of log4j - and says that in clear words at it's homepage. Of courser there is an exhaustive list of features / benefits that Logback claims over Log4j. You can read about them at this link. That's it really. The point of this article is that I am suggesting that while designing and developing a enterprise grade java based applications, look at logging a bit more carefully and also consider using Logback.

A few of the audience at this point, I am hoping, will like to roll up their sleeves, fire up their favorite editor and take Logback out for a spin. If you are one of them, then you and I have something in common. You might want to read on.

The very first thing that Logback promises is faster implementation (at this link). Really? I would like to check that claim.

I start by creating a vanilla java application using Maven. 

File: MavenCommands.bat

call mvn archetype:create ^
 -DarchetypeGroupId=org.apache.maven.archetypes ^
 -DgroupId=org.academy ^
 -DartifactId=logger

This unfortunately is preloaded with JUnit 3. I set up JUnit 4 and also add Contiperf, so that I could run the tests multiple times - something that would come in handy if I were to check performance.

File: /logger/pom.xml

[...]

<junit.version>4.10</junit.version>         
<contiperf.version>2.2.0</contiperf.version>

[...]
                         
<dependency>                                
 <groupid>junit</groupid>                
 <artifactid>junit</artifactid>          
 <version>${junit.version}</version>     
 <scope>test</scope>                     
</dependency>                               
     
<dependency>                                
 <groupid>org.databene</groupid>         
 <artifactid>contiperf</artifactid>      
 <version>${contiperf.version}</version> 
 <scope>test</scope>                     
</dependency>

Also, I like to explicitly control the java version that is being used to compile and execute my code.

File: /logger/pom.xml

[...]

<maven-compiler-plugin.version>2.0.2</maven-compiler-plugin.version>
<java.version>1.7</java.version>                                    

[...]
 
<plugin>                                                        
 <groupid>org.apache.maven.plugins</groupid>                 
 <artifactid>maven-compiler-plugin</artifactid>              
 <version>${maven-compiler-plugin.version}</version>         
 <configuration>                                             
  <source>${java.version}                        
  <target>${java.version}</target>                        
 </configuration>                                            
</plugin> 

Last of configurations - for the time being. Slap on surefire to run unit tests.

File: /logger/pom.xml

[...]

<maven-surefire-plugin.version>2.12</maven-surefire-plugin.version>                                

[...]
                         
<plugin>                                                        
 <groupid>org.apache.maven.plugins</groupid>                 
 <artifactid>maven-surefire-plugin</artifactid>              
 <version>${maven-surefire-plugin.version}</version>         
 <dependencies>                                              
  <dependency>                                            
   <groupid>org.apache.maven.surefire</groupid>        
   <artifactid>surefire-junit47</artifactid>           
   <version>${maven-surefire-plugin.version}</version> 
  </dependency>                                           
 </dependencies>                                             
 <configuration>                                             
  <argline>-XX:-UseSplitVerifier</argline>
 </configuration>                                            
</plugin>        
Please note, I have taken the pains of adding all these dependencies to this article with their versions, just to ensure that should you try this yourself, you know exactly what was the software configuration of my test. 

Now, let us finally add the unit tests.

File: /logger/src/test/java/org/academy/AppTest.java
public class AppTest {                                 
 private final static Logger logger = LoggerFactory 
   .getLogger(AppTest.class);                 
                                                       
 @Rule                                              
 public ContiPerfRule i = new ContiPerfRule();      
                                                       
 @Test                                              
 @PerfTest(invocations = 10, threads = 1)           
 @Required(max = 1200, average = 1000)              
 public void test() {                         
  for(int i = 0; i<10000 ; i++){          
   logger.debug("Hello {}", "world.");        
  }                                              
 }                                                  
}  

So, we have used the logger in my unit test but have not added an implementation of logger. What I intend to do is to add log4j (with slf4j) and logback (with inherent support of slf4j) one by one and run this simple test multiple times to compare performance.

To add log4j I used this setting.

File: /logger/pom.xml

<dependency>                                
 <groupid>org.slf4j</groupid>            
 <artifactid>slf4j-api</artifactid>      
 <version>${slf4j.version}</version>     
</dependency>                               
<dependency>                                
 <groupid>org.slf4j</groupid>            
 <artifactid>jcl-over-slf4j</artifactid> 
 <version>${slf4j.version}</version>     
 <scope>runtime</scope>                  
</dependency>                               
<dependency>                                
 <groupid>org.slf4j</groupid>            
 <artifactid>slf4j-log4j12</artifactid>  
 <version>${slf4j.version}</version>     
 <scope>runtime</scope>                  
</dependency> 

and for logback I used this setting.

File: /logger/pom.xml

<dependency>                                
 <groupid>ch.qos.logback</groupid>       
 <artifactid>logback-classic</artifactid>
 <version>${logback.version}</version>   
</dependency>   

with the following versions.

File: /logger/pom.xml

<slf4j.version>1.6.1</slf4j.version>    
<logback.version>1.0.6</logback.version>

Finally, for the moment of truth. I ran the tests thrice with each framework i.e. logback and log4j. Essentially I log.debug() a string 1000,000 times in each test and timed them. And this is how the final figures came out.

Framework1st run2nd run 3rd run
Logback 0.375 seconds0.375 seconds0.406 seconds
Log4j 0.454 seconds0.453 seconds0.454 seconds

As far as this little experiment goes, Logback clearly performs faster than Log4j. Of course this is overly simplistic experiment and many valid scenarios have not been considered. For example, we have not really used vanilla log4j. We have used log4j in conjunction with the slf4j API, which is not quite the same thing. Also, being faster is not the only consideration. Log4j works asynchronously (read here and here) whereas as far as I know Logback does not. Logback has quite a few nifty features that Log4j does not.

So, in isolation this little code does not really prove anything. If at all, it brings me back to the first point that I made - Logback is a serious potential and worth a good look if you are designing / coding an enterprise grade java based application.

That is all for this article. Happy coding.

Note: The original article is available at author's blog. Click here.

Published at DZone with permission of Partha Bhattacharjee, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Liam Knox replied on Mon, 2012/07/09 - 5:09pm

Logback is the supercede of log4j:  http://logback.qos.ch/

So what are you trying to compare here? This article sounds like you are trying to compare chalk and cheese rather than assessing a later version of for all respects is the same API.

Log4j and Logback can work in an sychronous and asynchronous fashion, though to be honest I would consider async logging madness in most applications  i.e. correlation to real time and other events like database access becomes void.

I don't really understand why DZone has published this article?  The main of the contents a cut a pasted pom file.  There is no evidence of the tests performed, iterations, anaylsis of difference, profile etc, etc, which is the subject of the post.  

Honestly does the DZone have any technically astute people to validate these articles or any editorial capacity?

I can summarize this article in total competeness as 'Hey I compared Logback and Log4j and Logback was a bit quicker !'.   Can the DZone please publish this sentence instead of this post as you can ommit the link and the subject can describe the total article.

Sam Lewis replied on Mon, 2012/07/09 - 5:34pm

It bugs me that there are so many choices for logging in java but none of them use the 'new' java 1.5 varargs language feature:

debug(String format, Object... args) 

 

I am almost tempted to write yet another logging facade for java :-) but slf5j and log5j beat me to it.

Surely it is time for LogBack and SLF4J to ditch java 1.4 support - give us the vararg!

Liam Knox replied on Mon, 2012/07/09 - 7:46pm in response to: Sam Lewis

I think it is criminal that the original JDK, or at least from 1.2, didn't have any logging support idea.  And when Sun did try to add it, when there were good proven implementations now, it was a right pigs ear of a solution and design. This says a lot for Sun at that time. Date, Format, many other API's are all waughts on what probably is the best language of our time.  Java is great the API's built in with the JDK are a mixed blessing.

Your right on this. The base interfaces should be in the JDK and extended through this. Its not too late I feel. Vargs support also fits naturally with the evolution of the JDK. I cant see that a Logger interface is that hard to maintain. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.