What is JAMon?

The Java Application Monitor (JAMon) is a free, simple, high performance, thread safe, Java API that allows developers to easily monitor production applications.  JAMon 2.2 requires JDK 1.4 or higher; however, previous versions of JAMon are available for JDK 1.2.

 

How can JAMon be used to test applications?

Despite the fact that JAMon was developed primarily to monitor applications in production, it can also be used during an applications testing/Q&A phase.  The following are some of the ways JAMon can be used in the testing phase:

 

·                     To ensure the application meets its performance requirements

·                     To ensure the application meets its scalability requirements

·                     To detect if the application has any errors or throws unwanted exceptions

·                     To ensure that that all parts of the application were properly tested (coverage)

·                     To ensure that the application is properly working in production as part of post-production testing

·                     To gather information from production and start a feedback loop between development, test and production that will improve the application

 

These topics will be elaborated on in subsequent sections.

 

 

What type of statistics does JAMon track, and how can I view them?

JAMon can be thought of as a software stopwatch that associates a label with aggregated execution times, and some other statistics. The fact that JAMon doesn't 'know' what this label represents, allows JAMon to flexibly track performance of just about anything (JSPs, methods, SQL statements, etc.).  Every time the JAMon start/stop methods (discussed below) are called with the same label, the following statistics are tracked.

 

·                     Aggregate performance statistics including - hits, average time, minimum time, and maximum time.  If our label represents a JSP  (for example: start("HomePage.jsp")), then representative page statistics might be that it executed 100 times, averaged 500 milliseconds (ms.), had a minimum of 100 ms., and a maximum of 8000 ms.

·                     Concurrency statistics including -  How many threads of execution for a label are currently running?  What was the maximum number of simultaneous threads of execution that ran?  If our label represented an SQL query (for example: start("select * from table where name=?")), then we could tell if this query is currently running. If the query is running, then we could see how many are running. We could, furthermore, view the maximum number of concurrent instances of this query that ran. 

·                     Date/Time information -  When was the code associated with the label first executed, and when was it most recently executed?  If our label represents a method name (for example: start("com.mypackage.MyClass.myMethod()")), then representative data might be that the method was first executed at '09/19/06 9:21 PM' and most recently executed at '09/22/06 9:30 AM'.

 

JAMon statistics are viewable via reports in the JAMon web application, and can also be accessed via JAMon method calls.

 

How can I incorporate JAMon into my application?

Developers can incorporate JAMon into their applications using any or all of the following approaches:

 

·                     Use the JAMon Servlet Filter - The JAMon servlet filter automatically passes web application page names (Servlets, JSPs and more) to the JAMon start/stop methods and, thus, allows developers to track page performance WITHOUT changing a line of application code.  All that is required is to copy a few standard lines into the applications web.xml file. 

·                     Use the JAMon JDBC Driver - The JAMon JDBC driver is a proxy that can monitor ANY JDBC driver (it has been tested against Sybase/MySQL/Oracle/HSQLDB and others), as well as  track JAMon statistics for SQL Commands, JDBC method calls, and SQL Exceptions.  It also tracks the N most recent queries executed and N most recent exceptions thrown.   Using the JAMon JDBC driver does not require ANY application code changes.  Just replace the original driver information (driver class name, and URL) with JAMon's.

·                     Use JAMon Interface Monitoring – As seen below, you can monitor ANY java interface simply by passing an implementation of the interface to the JAMon monitor method, and then call methods on the object as you would if the object wasn't monitored.  The class and method signature will appear as a label in the JAMon reports:

 

MyInterface myObject=(MyInterface) MonProxyFactory.monitor(new  MyImplementation());

            myObject.myMethod(); // Monitored!

 

·                     Finally, you can explicitly call the JAMon start/stop methods in the following manner.  Also, note that due to the fact that the JAMon label is simply a Java String,  dynamic/runtime data, such as a user name, can easily be incorporated into the label.

 

                        import com.jamonapi.*;

 

// page hits by user name using runtime data

 

            Monitor mon = MonitorFactory.start("homePage.jsp-"+userName);             ...code that you wish to time...

                        mon.stop();

 

How can JAMon used to test Applications? The Details

As testers use the application, JAMon statistics will automatically be gathered.  When testing is done the JAMon reports can be saved and reviewed.  The JAMon data can be used in the application testing phase in the following ways:

 

·                     To ensure the application meets its performance requirements - The JAMon reports can be reviewed to ensure performance requirements, such as the following, are met: 'No web page will exceed 10 seconds',  'All pages must average less than one second'. In a similar manner SQL performance requirements could be tested. 

·                     To ensure the application meets its scalability requirements - The JAMon statistic 'Max Active' indicates the maximum number of concurrent threads that ran with the given label.   If there is a requirement that the application has certain performance metrics under a given load (say 100 simultaneous page requests), JAMon report can be reviewed to ensure the load test generated the expected load, and that the application has acceptable performance metrics under this load.

·                     To detect if the application has any errors or throws unwanted exceptions - Often testers can't tell when Exceptions occur, as often code silently continues when an Exception occurs.  An example is when a caught SQL Exception is written to the log, and no other action occurs (the Exception is not re-thrown).  If the JAMon JDBC driver is used, all SQL exceptions will show up in the JAMon reports regardless if the exceptions are re-thrown or not.   In addition, custom JAMon labels can be created that indicate application errors have occurred. For example, a servlet filter could call JAMon to indicate the HTTP status of a page (You could use the JAMon add method to do this:  MonitorFactory.add("HTTP Status", "Error", httpStatusCode)).  Developers could also create a log4j appender that creates a JAMon record whenever a log4j error method is invoked that exceeds a specified severity threshold. There are many more examples of how programs can detect errors and create JAMon labels, thus enabling errors to be viewed in the JAMon reports.  If these steps are taken, testers can easily review the JAMon reports to ensure no errors have occurred in the application.

·                     To ensure that that all parts of the application were properly tested (i.e. coverage) - JAMon reports can be reviewed to ensure that all pages and SQL were successfully executed during the testing phase. 

·                     To ensure the application is properly working in production as part of post-production testing - Often times when an application is deployed, production steps are missed, and an application is missconfigured.  Testers can run the application after it has been deployed to production to ensure that it is working properly.   For example, testers could click on new functionality in a web application, ensure that no errors show up in the JAMon report, and ensure the application meets its production performance requirements.  The production JAMon report could also be saved as part of this final testing step.

 

How else can JAMon help improve applications?

Because JAMon is part of the application, it moves with the application automatically through its life cycle of development/test (Q&A)/production.  This allows developers and testers to improve application quality by gathering statistics in each phase, using the data to improve the next phase, and then finally start this process again in the subsequent release.  Examples follow:

 

- Developers can use JAMon in the development phase similarly to the way testers use it in the testing phase (discussed above).  This will ensure that many problems are caught before the formal testing phase even begins.

- JAMon shows its true value while running in production environments.  Some of the examples below show how production JAMon data can be used to improve tests, and also the application by helping the development team to gain a better understanding of how users interact with the application:

·                     What is the application's peak usage time?  - This could be used to determine a window for application maintenance.

·                     What is the maximum number of simultaneous users for the application? - This could be used to improve scalability testing.  There is no better load testing than your real users in action.

·                     Who are the application's "power users"? - Power users could be contacted to determine what they like and don't like about the system.

·                     Are certain application pages never used? - This information could be used to eliminate pages or possibly redesign them if they are not currently useful.

·                     When did a specific user last login to the application?

·                     What are the most commonly searched product categories? - This information could be used to redesign to make searching in these categories easier.

- JAMon can be used to help set coding priorities - Coding priorities can be based on factors such as which features are accessed the most often or what code is the slowest.

- To determine what is happening in an application at a snapshot in time - Many monitoring tools monitor an application from the "outside looking in", but because JAMon looks at the application from the inside we can use statistics such as "Active", "First Access" and "Last Access" to determine what activities our application is performing at any given time.  The ability to look 'inside' your application can be crucial when trouble shooting production problems.  Types of information that can easily be tracked include: Are database connections being closed?; Are exceptions being thrown?; What SQL is currently executing?; and much more.

 

Where can I learn more?

This was just a brief introduction of some of the ways JAMon can be used. To learn more go to http://www.jamonapi.com.  To see a live demo of JAMon and to view the JAMon statistics go to http://www.ssouza.com/jamon.