You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Adrian Crum (JIRA)" <ji...@apache.org> on 2013/05/21 10:01:23 UTC
[jira] [Comment Edited] (OFBIZ-5198) Add a mean to collect and show
the Requests Events durations using Metrics
[ 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: adrianc@hlmksw.com):
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