Java(TM) Execution Time Measurement Library

Runtime performance monitoring made easy

JETM Springframework 2.x integration

If you already use the new Spring 2.x schema based configuration you can use the JETM namespace to configure performance monitoring. Otherwise use Spring 1.x dtd based configuration.

Be aware that these prerequisites and constraints apply.

Performance monitoring step-by-step

Step I: Initialize JETM runtime

In order to enable performance monitoring the JETM runtime has to be configured. Therefore you need to add the JETM namespace and a tag called jetm:runtime to your Spring 2.x configuration.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jetm="http://jetm.void.fm/schema/jetm_spring_config_1_2"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                           http://jetm.void.fm/schema/jetm_spring_config_1_2
                             http://jetm.void.fm/schema/jetm_spring_config_1_2.xsd">

  ...
    
  <jetm:runtime />

  ...  
</beans>

Since the runtime should exist globally you need to ensure that the runtime definition happens in your spring configuration root. Otherwise child definitions may not be able to access the runtime.

Step II: Monitor Spring managed beans

The tag jetm:monitoring will register Spring managed beans for performance monitoring. Once registered the JETM runtime will record execution times of all public methods in those beans. Simply supply a comma separated list of bean names you are interested in. Use wildcards if you want.

<jetm:monitoring>
  <jetm:bean-pattern>*Service,MyBean</jetm:bean-pattern>
</jetm:monitoring>

Step III: Access aggregated results

The standalone HTTP console provides access to aggregated performance results. Simply add the following fragment to your Spring configuration and point your browser to http://{HOSTNAME}:40000 to access it.

<jetm:console />

If your application is a web application you probably want to use the servlet based monitoring console instead. See Spring web integration for further details.

Further configuration options

So far we have been using default configurations only.

The tag jetm-runtime configures the JETM runtime using the defaults nested monitor, best available timer and threshold based buffering (1000 measurements). The tag jetm-console will launch a HTTP console at port 40000. And both jetm-monitoring and jetm-console automatically locate the JETM runtime by looking for a spring managed bean implementing the interface EtmMonitor.

Of course all those defaults may be altered.

JETM runtime attributes

The tag jetm-runtime supports the optional attributes type and timer. The attribute type defines the type of the monitor. Use nested, flat or a full qualified class name that implements EtmMonitor. The attribute timer defines the type of the timer. Use jdk15, sun, default or a full qualified class name that implements ExecutionTimer.

<jetm:runtime type="flat" timer="default" />

JETM aggregation chain

As stated above the default aggregation chain uses a threshold based buffer. If you want to alter this behavior you may chose between activating a distinct feature from a predefined set or specifying the complete aggregator chain manually.

The nested element jetm:features supports access to predefined JETM aggregation features. Currently it is possible to alter the buffering capabilities, enable aggregation persistence and raw data logging. For further details see nested elements jetm:interval-buffer, jetm:threshold-buffer,jetm:persistence and jetm:raw-data-log in JETM spring configuration schema.

The following example buffers collected details for 5000 miliseconds before aggregation. Furthermore aggregated performance results are persistent and will survive VM restarts, see Aggregation Persistence for details.

<jetm:runtime>
  <jetm:features>
    <jetm:interval-buffer interval="5000"/>
    <jetm:persistence />
  </jetm:features>
</jetm:runtime>

Alternatively you may define the used aggregation chain similar to xml-based EtmManager configuration. The chain consists of one root chain element and n chain elements that process recorded execution times in the specified order.

<jetm:runtime>
  <jetm:aggregator-chain>
    <jetm:chain-element class="etm.core.aggregation.BufferedTimedAggregator">
      <jetm:property name="aggregationInterval">10000</jetm:property>
    </jetm:chain-element>

    <jetm:chain-element class="etm.contrib.aggregation.log.CommonsLoggingAggregator">
      <jetm:property name="logName">my.application.raw-performance-data</jetm:property>
    </jetm:chain-element>
    
    <jetm:chain-root class="etm.core.aggregation.RootAggregator" />
  </jetm:aggregator-chain>
</jetm:runtime>

JETM runtime plugins

Again - similar to xml-based EtmManager configuration you can register EtmPlugins to a JETM runtime. Use the nested jetm:plugin element to do so.

<jetm:runtime>
  <jetm:extension>
    <jetm:plugin class="etm.contrib.renderer.plugin.Log4jDumpOnShutdownPlugin">
      <jetm:property name="logName">my.log.category</jetm:property>
    </jetm:plugin>
  </jetm:extension>
</jetm:runtime>

JETM runtime references

Most likely you will never have more that one JETM runtime in your Spring configuration. In the unlikely event of having more than one add an id to your JETM runtime and use the attribute runtime-ref to refer to it.

<jetm:runtime id="monitorOne"/>

<jetm:runtime id="monitorTwo"/>

<jetm:monitoring runtime-ref="monitorOne">
  <jetm:bean-pattern>*Service,MyBean</jetm:bean-pattern>
</jetm:monitoring>

<jetm:console runtime-ref="monitorOne"/>

Standalone HTTP console properties

The build-in console can be configured using the optional attributes listen-port, worker-size and runtime-ref.

<jetm:console listen-port="45000" worker-size="3"/>