The Disco Blog Welcome Guest | Login or Register

Verifying application performance is almost always a secondary concern during application development. Mind you, I’m stressing the verification of application performance, man. An application’s performance is always a chief concern from day one, but rarely is it verified until much, much later.

There are a number of copasetic reasons why performance testing is put off until it later cycles; however, in my experience, it seems most businesses don’t truly take application performance testing seriously because they don’t know what to expect. Of course, numbers are thrown out in the beginning stages; however, reality is almost always different– either the application performs much lower than expected or things take off like wild fire.

Performance testing usually becomes a primary concern once two square things happen:

• there is a noticeable performance problem in production
• a customer or prospective customer demands to know performance numbers

There is an easy way; however, to ascertain basic low level performance numbers using existing JUnit assets. Via the JUnitPerf framework, existing JUnit tests can be quickly turned into simple load tests and even stress tests.

JUnitPerf can create two types of hip tests using the decorator pattern– TimedTests and LoadTests using JUnit’s suite mechanism. TimedTests create a top level bound for a test case– if this time is surpassed then the test fails. LoadTests work in cooperation with timers and create an artificial load on a particular test case by running it a desired amount of times separated by the configured timer.

For example, the TimedTest below will run the testToXML test case once and if this test case takes longer than 170 milliseconds the test case will fail.

public static Test suite() {
 long maxElapsedTime = 170; //170 milliseconds
 Test testCase = new BatchDepXMLReportPerfTest("testToXML");
 //passing false to this constructor would fail the
 //test immediately if test exceeded 170ms
 //otherwise this test finishes and is failed if > 170ms
 Test timedTest = new TimedTest(testCase, maxElapsedTime);
 return timedTest;
}

In the suite method below, a LoadTest is defined, which will run the testFindVerifyDefinition test case 10 times, each thread launching every 100 milliseconds.

public static Test suite() {
 int users = 10;
 Timer timer = new ConstantTimer(100);
 return new LoadTest(
  new WordDAOImplLoadTest("testFindVerifyDefinition"),
    users, timer);
}

Using this keen framework, basic performance measures can be put into place, which can give a baseline breaking limit on low level application code, such as:

• how long it takes for the executeTrade method to complete
• how long does it take for this same method to complete under various load scenarios

Plus, this framework can reuse your existing JUnit tests that already verify the executeTrade method! What a trip!

Trackback this Post | Feed on comments to this Post