JETM Advanced concepts
While basic concepts introduced the rationale behind JETM the following page covers JETM from an architectural point of view. It will offer a detailed description of its main features and extension points.
Bits and Pieces: EtmPoint, EtmMonitor, Aggregator
JETM uses a simple concept to measure and visualize application performance. With the help of an EtmPoint an EtmMonitor collects individual performance statistics and uses a chain of aggregators to process those raw results. This aggregator chain was introduced to support flexible multi-staged processing of raw performance data.
For example an aggregator chain could buffer raw performance data and aggregate them asynchronously. Or simply log raw data and move the aggregation to an external process (e.g. RRDTool). The chain may be configured at EtmMonitor construction time - see five minute tutorial - or using the JETM static configuration mechanism.
There are two different types of EtmMonitor available: The NestedMonitor collects performance data such that nested EtmPoints will retain their execution path. The FlatMonitor however will identify EtmPoints points by name and discard the execution path. Please note that nested collection adds some overhead (due to the usage of ThreadLocals).
Static vs. Non-Static Usage
As seen in one minute tutorial JETM can be easily used just like a logging frameworks. The drawback of this strategy is that application code contains performance measurement code that can't be added or removed easily.
Therefore it is recommended to use declarative performance monitoring using AOP. One example is Springframework based performance monitoring that removes the need to alter application code.
MeasurementRenderer - Rendering aggregated results
Usually the drop-in HTTP console will be sufficient to visualize performance results. Nevertheless a JETM MeasurementRenderer can be used to access the current aggregated performance results by calling the EtmMonitor method render(MeasurementRenderer).
Currently JETM ships with three basic MeasurementRenderer implementations (Standard Out, HTML and Swing), however implementing a custom rendering mechanism is pretty straight forward: A MeasurementRenderer requires the implementation of the method render(Map) that provides access to all available performances statistics.
Accessing raw measurement results
Even though JETM should be used to generate aggregated performance results raw data logging is supported too.
By addding a specific logging aggregator raw data can be written to any destination. JETM ships with adapters to all major Java™ logging frameworks (commons-logging, log4j and java.util.logging) that can easily be added to an existing aggregator chain and thus enable raw data logging transparently. One of the major advantage is that the log output will be consistent accross the application.
It is recommended to add an asynchronous buffering aggregator in front of an logging aggregator in order to limit negative side effects (performancewise). A typical logging aggregator chain should look like this:
The aggregator chain above will buffer raw performance results for a certain period of time (default is 5 seconds). It will then flush those results, which means writing raw performance results to a commons logging destination (default etm-raw-data) and aggregate them using nested aggregation.
Next...
Now proceed to five minute tutorial to see some of theses features at work.