Java™ Execution Time Measurement Library

Java™ 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. Otherwhise 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. Otherwhise 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 aggreation 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
"/>