Newsletters Subscriptions Media Kit About Us Contact Search Home

Stuff
OS/400 Edition
Volume 2, Number 12 -- June 5, 2003

Measuring Performance from the Java Side


by Marc Logemann

[The code for this article is available for download.]

Achieving good performance is critical in each software project. This article will focus on JDBC performance measuring and will cover how you can check the speed of selected code blocks. All this from the Java perspective, without the need to use any iSeries tools. The tools used throughout this article are open source and free of charge.

The Open Source Performance Tools

To do the measuring, I will use four open source tools. SQLProfiler is the one that will do the JDBC tracking; this software uses two other open source projects, called Log4J and P6Spy, to do its work. To understand what SQLProfiler does, it's necessary to see what the other two tools do. P6Spy is a pass-through JDBC driver. I will use this driver later on, instead of the IBM DB2 driver. Of course, we have to configure P6Spy so that it will use the IBM driver at runtime. Log4J will collect the performance data from P6Spy and send it to a socket. At the end of the chain works SQLProfiler, which will collect the data from the socket and display it to the user via a Java GUI application. You see, a lot of software interaction will go on, but it's worth the work: You get all measurement for free.

The last tool used in this article, JAMon, is quite unknown but can help you check how code blocks perform without using the old-fashioned System.currentTimeMillis() and the resulting computation of the two values afterward. This one I am using for each and every project I work on, and I think it's worth checking out.

Installing SQLProfiler and Its Friends

Installing SQLProfiler starts by downloading the different tool's archives. The table below shows the URLs where you can get the tools.


Tool Location
SQLProfiler www.jahia.org/jahia/page377.html
Log4J http://jakarta.apache.org/log4j/docs/index.html
P6Spy www.p6spy.com
JAMon www.javaperformancetuning.com/tools/jamon/index.shtml

When you finish the download procedure, extract the four archives into different folders, like /java/performance/SQLProfiler and /java/performance/log4j.

Place the Log4J jar file, which you can find in the dist/lib folder of your log4j installation, in the Extension Classpath of your Java Runtime. This classpath can usually be found in your JAVA_HOME folder, under /jre/lib/ext. You can also try to put the log4j jar file only in your application classpath, but I had some weird classloader problems with P6Spy, so putting it in /jre/lib/ext will work. If you want to know more about Extension Class Loading and Classloaders in general, check the Sun Microsystems tutorial.

In your SQLProfiler installation folder, you will notice a spy.properties file. This file is the configuration file for P6Spy. It will be loaded when you register the P6Spy driver in your Java code. Modify the file as mentioned below. The "realdriver" directive must match to the fully qualified classname of the iSeries JDBC driver. The "logfile" directive should point to some location on your hard disk. Of course you can choose any other folder; just make sure you use slashes instead of backslashes when you are on a Microsoft-based operating system.

# ibm db2 driver
realdriver=com.ibm.as400.access.AS400JDBCDriver

# name of logfile to use, note Windows users should 
   make sure to use forward 
# slashes in their pathname (e:/test/spy.log) (used 
   for file logger only)
logfile     = c:/spy.log

Furthermore make sure that only one realdriver line is active, and comment any other realdriver lines with a pound sign (#). Don't append realdriver or logfile at the end of the file. The lines containing realdriver and logfile are already there; just modify them.

When you are done, place the spy.properties file in your build folder. This is the folder where your compiled Java class files will reside.

All you have to do later on is to put three other JAR files in your classpath: the p6spy.jar, which can be found in the P6Spy installation folder, the JAMon.jar, which can be found in the JAMon installation folder, and the jt400.jar, which you might know already, because there you will find the iSeries DB2 JDBC driver.

Code Integration of the Performance Tools

Integrating the SQL profiling into your Java code is quite easy. Just see the example below for a very simple application, using the driver.

public class PerfTest {

   public static void main(String[] args) {
      try {
         Class.forName(
              "com.p6spy.engine.spy.P6SpyDriver").newInstance();
         Connection c = 
       DriverManager.getConnection(
              "jdbc:as400://100.100.100.100;"+
       user=user;password=mypassword;prompt=false;" +
                 "naming=system;libraries=logemann");
         String sql = "select * from j_jus";
         Statement statement = c.createStatement();
         ResultSet resultSet = statement.executeQuery(sql);
         int i = 0;
         while (resultSet.next()) {
       i++;
       System.out.println("Record Number: "+i);
         }
      } catch (InstantiationException e) {
         e.printStackTrace();
      } catch (IllegalAccessException e) {
         e.printStackTrace();
      } catch (ClassNotFoundException e) {
         e.printStackTrace();
      } catch (SQLException e) {
         e.printStackTrace();
   }
 }
}

You see, the program is not very special, but instead of loading the JTOpen DB2 JDBC driver directly, it loads the P6Spy JDBC driver, which connects to the DB2 in the background. So it's something like a JDBC proxy with some special features like logging.

When compiling and running this program, you must have the following JAR files in your classpath: p6spy.jar and jtopen.jar.

When you run this program, you will get the following error:

log4j:ERROR Could not connect to remote log4j server 
   at [localhost]. We will try again later.

To understand this, you have to remember that P6Spy will log any performance data to a socket. This is not the case per default. It's because we provided our very own p6spy.properties file from the SQLProfiler distribution. With the socket connection, you always need a serversocket and a clientsocket. P6Spy opens a clientsocket, but we have not opened a serversocket yet. Here, the SQLProfiler tool comes into play.

Change to the folder where you installed SQLProfiler. Run the GUI tool with the following statement on your shell:

java -jar sqlprofiler.jar

Of course it is assumed that the java tools like "java" or "javac" are in your path environment variable, so you don't need to specify the location of the tools on the command line.

After issuing the command, you will see a screen like that in Figure 1.

Figure 1

Figure 1: SQLProfiler in its initial state

After starting the SQLProfiler, which listens on a socket at port 4445, you see that the tool can't find a P6Spy powered program. So the red lights in the status bar appear. But when you run the Java program while the SQLProfiler is open, you will see a screen like that in Figure 2.

Figure 2

Figure 2:SQLProfiler with connected application

As you can see, the status bar has a green light to indicate that a program that uses the P6Spy JDBC driver is up and running. After several starts of our custom Java application (remember that the PerfTest application terminates after looping through the ResultSet) and hitting the Pause button of the SQLProfiler, you will see a screen like that in Figure 3.

Figure 3

Figure 3: SQLProfiler with detailed SQL stats from the application

From here you can start your performance analysis. You see how much time each SQL request consumed and how many calls per table were made. In my example you see a very poor performance of my iSeries DB2. That's the case because our simple PerfTest application creates a new DB2 connection on the iSeries for every query. If you run the same query two times in the Java application, you will see that the second database query is a lot faster. Of course it's highly recommended to use db connection pools on the iSeries.

This trivial example should be enough for the first run. If you have an application, it should be no problem to change the JDBC driver and use this performance measurement strategy. For more details on how exactly to increase the JDBC performance, I recommend Howard F. Arner's article "ADO/JDBC Performance Using Parameters" and IBM's recommendations.

Using JAMon for Easy Block Performance Measurement

After introducing a way to trace JDBC performance, I will end this article by showing an easy way to replace the ugly System.currentTimeMillis() way of capturing elapsed seconds in some code block. All you have to do is to place the jamon.jar from the jamon installation folder in your application's classpath. Then instead of writing code like this:

long l = System.currentTimeMillis();
// some operations…
long l2 = System.currentTimeMillis();
System.out.println("elapsed Time in Millis: "+(l2 – l));

You want to write the following code:

Monitor mon = null;
mon = MonitorFactory.start("myFirstMonitor");
// some operations
mon.stop();
System.out.println(mon);

The output of the second approach would be this:

1.502 ms. (Hits=1  Avg=1.502 ms. Total=1.502 ms. 
   Min=1.502 ms. Max=1.502 ms. Active=0  Avg Active=1  
      Max Active=1  First access=26.05.03 13:47:55  
       Last access=26.05.03 13:47:57  )

Of course, you can output the different values explicitly by calling the appropriate Object Attributes, instead of calling the toString() method of the Monitor object.

In our JDBC example, you could wrap the first two statements in the try block with the code block just mentioned, using JAMon. This way you can easily see how much time your iSeries consumes when creating physical JDBC connections to the iSeries.

There is nothing that prevents you from getting several different Monitors and using them throughout your code. Just call the Factory method start() of the MonitorFactory class with a different name. More detailed examples can be found on the JAMon home page mentioned in the table above.

What I Really Need

These are only two ways of measuring Java performance, but there are a lot more. For a more detailed output of time consumption inside methods or memory usage of objects, there are many commercial profilers, like JProfiler or JProbe. In real-life projects, I would recommend starting by using the free performance tools available. You will discover major performance problems without a hassle. If you conclude that you need more details, the commercial products are ready to help.

You can download the PerfTest source code here. Don't forget to change the JDBC URL to suit your needs. There is also a sample spy.properties file for download, which should work for all Windows-based systems. If you are on a Unix-style operating system, just change the logfile line.


Marc Logemann is a senior e-business consultant at Spirit/21 AG, a German consulting company that focuses on iSeries services and development. Marc is involved in Java- and PHP-based open-source projects and likes reading books about new technologies. E-mail: mlogemann@itjungle.com


Sponsored By
ASNA

Why Roto-Rooter Uses ASNA Visual RPG for Application Development

Roto-Rooter knew that the time had come to replace their green-screen technician dispatch system. When they selected AVR as their development environment, they realized they would be able to use their existing RPG programming skills. They also found that they were able to program even faster than with traditional RPG. Their new AVR application includes capabilities not possible in the green-screen app, such as graphical representations of technician schedules, easy to access menus, and tabs that allow easy movement from screen to screen. These capabilities make their new application much easier for their users to learn and use than the old green-screen version. Since the application now features more information on the screen at one time, in a format that is easier to read, users are able to see and correct scheduling conflicts more quickly so they can provide a higher level of customer service.

"AVR has saved us so much time while working on our first visual application. I would say that we are able to cut our programming time, just for subfiles, in half and we use subfiles in over 90% of the programs that we have created for this project. It's really nice to be able to move our employees from dumb terminals to PCs and get them using more useful and user friendly applications."
--Tom Duebber

Download your FREE copy of ASNA Visual RPG today!
http://www.asna.com/success_showcase.asp


THIS ISSUE
SPONSORED BY:

T.L. Ashford
ASNA
WorksRight Software
Profound Logic Software


BACK ISSUES

TABLE OF
CONTENTS
The Valuable NULL

Measuring Performance from the Java Side

Reading an IFS File from RPG

Become the Master of Your Subfile Domain


Editors
Shannon O'Donnell
Kevin Vandever

Managing Editor
Shannon Pastore

Contributing Editors:
Howard Arner
Raymond Everhart
Joe Hertvik
Ted Holt
Marc Logemann
David Morris

Publisher and
Advertising Director:

Jenny Thomas

Advertising Sales Representative
Kim Reed

Contact the Editors
Do you have a gripe, inside dope or an opinion?
Email the editors:
editors@itjungle.com


Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.