Why Stress Test Your Applications?

Performance Testing Your Beans

As already indicated, there's a difference between stress testing and performance testing; however, they usually are connected because one usually can have an impact on the other. Performance testing deals with areas of an application that are sluggish , even with a single user . Better coding methods or algorithms usually fix the problems you find when you do performance testing. For example, you might use an Object[] and a for loop to iterate through a finite collection, rather than an Iterator or Enumeration .

After you've identified the performance bottlenecks, manual code reviews usually are necessary to spot the causes of the problems. In some cases, you might find that you can change the way the code is written and get better performance. In other cases, it just might be a complicated algorithm and there's nothing you can do about it. These performance problems can usually be found easier by using performance-testing tools. Sometimes, these tools can easily indicate threads that are waiting for other threads to complete, or where a large number of objects are being created needlessly. Table 18.1 provides a small list of commercially available tools that can help you conduct performance testing.

Table 18.1. Several Performance-Testing Tools

Company	Product	URL
Rational	Quantify	www.rational.com
Sitraka	JProbe	www.jprobe.com
Intuitive Systems, Inc.	OptimizeIt	www.optimizeit.com
Apache Group	JMeter	jakarta.apache.org

Although these tools can reduce the amount of time it takes to identify the performance problems, they are rather expensive, and some of them take some time to learn to use. If you are limited by time and a budget, you can use some simple tests to get an idea of which components or operations are fine and which ones are slow. One of the easiest ways of doing this is to build a Java client that exercises each remote method in your EJB. Before you call the method, record the time and then record it again after the method is finished. If you take the difference of the start and end times, you can get an idea of how long each method takes to perform. Listing 18.1 illustrates this basic approach.

Listing 18.1 Simple Client Test to Get Bean Performance Times

 import java.util.Collection;  import javax.naming.Context;  import javax.naming.InitialContext;  import javax.naming.NamingException;  import javax.rmi.PortableRemoteObject;  import com.que.ejb20.auction.controller.AuctionHouse;  import com.que.ejb20.auction.controller.AuctionHouseHome;  public class AuctionHouseTest {   // Constructor    public AuctionHouseTest() {     super();    }    // Returns a remote interface to the AuctionHouseBean    private AuctionHouse getAuctionHouse() {     Context initCtx = null;      AuctionHouse auctionHouse = null;      try {       // Create the initial context        initCtx = new InitialContext();        Object obj =          initCtx.lookup( "AuctionHouse" );        // Narrow and cast the object        AuctionHouseHome auctionHouseHome =          (AuctionHouseHome)PortableRemoteObject.narrow( obj,                                                     AuctionHouseHome.class );        // Create a remote reference and store it into the instance reference        auctionHouse = auctionHouseHome.create();      }catch(Exception ex ) {       ex.printStackTrace();      }finally{       try{         if ( initCtx != null ){           initCtx.close();          }        }catch( Exception ex ){         ex.printStackTrace();        }      }      // Return the remote reference      return auctionHouse;    }    /**     * Test the enterprise bean's methods     */    private void runTest( AuctionHouse house ) {     try{       // record the start time        long beginTime = System.currentTimeMillis();        // Invoke the method        Collection auctions = house.getAllAuctions( 1, 10 );        // Record the end time        long endTime = System.currentTimeMillis();        // Print out the time that the method took        System.out.println( "Time: " + (endTime - beginTime) + " millisecs" );      }catch( Exception ex ){       System.out.println( "Problem running the test!" );      }finally{       // Clean up the remote reference        try{         if ( house != null )            house.remove();        }catch( Exception ex ){         ex.printStackTrace();        }      }    }    // The startup method    public static void main(String[] args) {     AuctionHouseTest test = new AuctionHouseTest();      AuctionHouse house = test.getAuctionHouse();      if ( house != null ){       test.runTest( house );      }else{       // If there was a problem, just exit        System.out.println( "Error creating AuctionHouse remote" );      }    }  } 

This is a very simple approach, but that's the point. You can get some very helpful results just by testing how long each bean method takes to execute. As you make changes to the bean or the environment configuration, you can execute these tests iteratively to see how the changes affect execution times. The example in Listing 18.1 only tests the getAllAuctions method and ideally , you would want to test each method available in the remote interface of the EJB.

Tip

It's a good idea to execute the tests many times and take an average of the execution times, primarily because of timer accuracy. Although the method currentTimeMills might return millisecond resolution, the PC clock the user can access is not that accurate. By running many loop iterations, you can eliminate some of the accuracy problems.

Results also can vary depending on which data set you are executing against and even the network traffic at the time of the tests. The best approach is to use a data sample that is typical of what the actual end users will use. Be sure the data in the database is an accurate sample of what it will be in the production environment, or you'll likely miss some problems.