Tracking and displaying performance metrics

Admin4J makes tracking performance easy. Optionally, adminsitrators can be notified when performance of an Http request exceeds a defined threshold.

Screen Shots

Admin4J Performance Statistics shot

Installing Performance Tracking

If you followed the installation procedure detailed in the Getting Started section, there is no need to install the Performance Metrics page separately. Only follow this procedure if you're not using the Admin4J Home Page Servlet.

Add the following filter and filter mapping to your applications web.xml:

<filter-name>Performance Filter</filter-name>

<filter-name>Performance Filter</filter-name>

The following configuration parameters are supported for the performance tracking filter.

Parameter Required Default Description N none. If set, a notification will be issued should a page take longer than the specified number of milliseconds. For this option to work, values must be provided for notifier
notifier N Defaults to default.notifier.class value in the Admin4J configuration. Handles admin notification. See documentation for the Notifier you're using for any additional configuration requirements. See Admin4J Notifiers section for more detail.
uri.consolidator N Defaults to no URI consolidation. Class name for consolidator that implements interface net.admin4j.ui.filters.consolidator.HttpRequestConsolidator. Bundled option is net.admin4j.ui.filters.consolidator.RestServiceHttpRequestConsolidator, which will consolidate RESTful web service URIs that include data as well as resource designations. If you specify RestServiceHttpRequestConsolidator, then you must include parameters rest.resource.tokens and rest.service.uri.prefix.
rest.resource.tokens N Required if URI consolidator RestServiceHttpRequestConsolidator is specified. Comma delimited list of REST resource identifiers. For example, "students,classes,charges". All other parts of the URI are ignored for performance tracking purposes.
rest.service.uri.prefix N Required if URI consolidator RestServiceHttpRequestConsolidator is specified. Identifies a URI prefix used for RESTful web services. For example "/services". This is needed so that URIs that aren't RESTful web services aren't ignored as data identifiers.

Tracking performance for items other than Http requests

Performance can be monitored for batch jobs or other transactions that aren't Http requests. In fact, the Performance Monitoring filter referenced above is a good example. You simply start a performance monitor at the beginning and stop the monitor at the end of the work to be measured. An example follows:

		import net.admin4j.timer.TaskTimer;
		import net.admin4j.timer.TaskTimerFactory;

		//  At the start of section to be monitored for performance.
		TaskTimer perfMonitor = TaskTimerFactory.start("My Label");

		//  At the end of the section to be monitored -- preferably in a 'finally' block.

Tracking performance for RESTful Web Services

Admin4J can optionally consolidate performance tracking for RESTful Web Service URIs as they contain specific data as well as resources. For example, tracking /services/students/12345 as a URI isn't useful as it names one specific data item. Tracking the mask /services/students/* is, however.

There are two options for configuring performance tracking for RESTful web services. If you registered the performance tracking filter via web.xml, then you should include init parameters specifications for uri.consolidator, rest.resource.tokens, and rest.service.uri.prefix as detailed above.

Additionally, you can configure the performance tracker via the file.

Tracking performance for Quartz Batch Jobs

Admin4J provides a Quartz Job Listener that can monitor performance for Quartz batch jobs. To install, just add the following line to your file:


Installing Performance Metrics Display

Add the following servlet and servlet mapping to your applications web.xml:

		<servlet-name>Performance Display Servlet</servlet-name>

		<servlet-name>Performance Display Servlet</servlet-name>
You might want to define a security constraint on the mapping to this servlet if you only want to provide display access to administrators and support personnel.