I have an application metrics feature working on my local copy and I was
wondering if there would be any interest in including it in the project.
A metric is a measure of average execution time. Each metric is given a
unique name.
I modified the control servlet and service dispatcher to use metrics. To
add a metric to a request, just include an XML element:
<metric name="URL: webtools/main" />
to the request map and the average response time for the URL will be
maintained. Likewise, to add a metric to a service, just include an XML
element:
<metric name="Service: createMaintsFromTimeInterval" />
to the service definition and the average execution time for the service
will be maintained.
Metrics are kept in memory. There is a service to retrieve all metrics.
There is also a Web Tools page to view all metrics.
A heartbeat server could retrieve the metrics to check on server load or
to provide histograms.
The metric element has an optional threshold attribute, so some action
could be taken when the metric crosses a threshold. For example, in the
following request map:
<request-map uri="ViewMetrics">
<security https="true" auth="true"/>
<metric name="URL: webtools/ViewMetrics" threshold="1000"/>
<response name="success" type="view" value="ViewMetrics"/>
<response name="threshold-exceeded" type="view"
value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
</request-map>
the ServerBusy view would be rendered if the average response time
exceeded 1000 mS. This can be useful for providing a lively web
experience on a heavy-traffic web page.
The service dispatcher does not use the threshold. I could not think of
a use case where service behavior should be modified based on average
execution time.
The metrics code is very small - two java files. Also, the modifications
to the webapp component and service component are very small.
What do you think?
-Adrian
