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.
// page hits by user name using runtime data
Monitor mon = MonitorFactory.start("homePage.jsp-"+userName); ...code that you wish to time...
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.