[
https://issues.apache.org/jira/browse/OFBIZ-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662789#comment-13662789
]
Adrian Crum edited comment on OFBIZ-5198 at 5/21/13 7:59 AM:
-------------------------------------------------------------
*Measuring request events only:*
{code}
<request-map uri="cancelSelectedOrderItems">
<security https="true" auth="true"/>
<event type="java" path="org.ofbiz.order.order.OrderEvents"
invoke="cancelSelectedOrderItems">
<metric name="Event: OrderEvents.cancelSelectedOrderItems" />
</event>
<response name="success" type="view" value="orderview"/>
<response name="error" type="view" value="orderview"/>
</request-map>
{code}
You will need to update the webapp code to support the new metric location.
*Visually sort metric types:*
The Web Tools screen sorts metrics by name, so you can prefix each metric name
with its type. For example "Request:", "Event:", "Service:", etc. Putting
different metric types in separate columns is a customization that should be
done on a local copy.
*Disable the smoothing factor:*
{code}
<metric name="Event: OrderEvents.cancelSelectedOrderItems" smoothing="1" />
{code}
*Disable the moving average:*
{code}
<metric name="Event: OrderEvents.cancelSelectedOrderItems" smoothing="1"
estimation-size="1000000" estimation-time="86400000" />
{code}
Technically, those settings will average service rates every 24 hours. The
default Metrics implementation could be modified to disable the moving average
if estimation-size and estimation-time are both set to zero.
Do not store properties settings in static final fields - that makes it
impossible to make run-time changes to the settings. Instead, retrieve the
settings in the factory method.
was (Author: [email protected]):
Measuring request events only:
{code}
<request-map uri="cancelSelectedOrderItems">
<security https="true" auth="true"/>
<event type="java" path="org.ofbiz.order.order.OrderEvents"
invoke="cancelSelectedOrderItems">
<metric name="Event: OrderEvents.cancelSelectedOrderItems" />
</event>
<response name="success" type="view" value="orderview"/>
<response name="error" type="view" value="orderview"/>
</request-map>
{code}
You will need to update the webapp code to support the new metric location.
Visually sort metric types:
The Web Tools screen sorts metrics by name, so you can prefix each metric name
with its type. For example "Request:", "Event:", "Service:", etc. Putting
different metric types in separate columns is a customization that should be
done on a local copy.
Disable the smoothing factor:
{code}
<metric name="Event: OrderEvents.cancelSelectedOrderItems" smoothing="1" />
{code}
Disable the moving average:
{code}
<metric name="Event: OrderEvents.cancelSelectedOrderItems" smoothing="1"
estimation-size="1000000" estimation-time="86400000" />
{code}
Technically, those settings will average service rates every 24 hours. The
default Metrics implementation could be modified to disable the moving average
if estimation-size and estimation-time are both set to zero.
Do not store properties settings in static final fields - that makes it
impossible to make run-time changes to the settings. Instead, retrieve the
settings in the factory method.
> Add a mean to collect and show the Requests Events durations using Metrics
> --------------------------------------------------------------------------
>
> Key: OFBIZ-5198
> URL: https://issues.apache.org/jira/browse/OFBIZ-5198
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Jacques Le Roux
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: OFBIZ-5198 metrics.patch
>
>
> *Requirements:*
> collect the durations of events (and only events) of a requests. This is
> currently missing for chained requests which are not using a service, either
> in Stats or Metrics. I have not looked into details of the Stats
> implementations but I did in Metrics.
> *What I found:*
> I want to use Metrics because I find its implementation easier to understand
> and modify than Stats. Also its UI is more legible. And I don't mind saving
> in DB, which anyway could always be added as an option from a properties.
> *What I did:*
> I figured out that to get this new measure, I need another column in Metrics
> UI and a related new variable in code. The existing serviceRate varialbe is
> fetched by getAllMetrics service and calculated by recordServiceRate()
> Metrics method. I added the possibility to change the 3 driving parameters
> (estimation size and time and the smoothing factor) with properties.
> *What want and did not want*
> I want to benefit from the existing Metrics framework, making the less
> changes as possible. I did not want to add a new controller element, nor even
> add an attribute to Metric element. Even if in some cases the new column will
> not be populated (services) or will have less interest (not chained
> requests). Luckily, the cost of calculating this new variable is very slow.
> I did not want to interfer with the existing code. Because it's only a
> measure which don't need the threshold feature. The easier way I found was to
> slightly modify the recordServiceRate() method. I introduced a
> requestEventRate variable which is only calculated for request (be chained or
> not). Actually what I call event is more the duration from the beginning of
> RequestHandler until the end of the called event. This is what matters when
> you want to measure the cost of interleaved/chained requests of a global
> request.
> *To test:*
> simply add a metric element to any request-map in a controller
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
