[ https://issues.apache.org/jira/browse/OFBIZ-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662789#comment-13662789 ]
Adrian Crum commented on OFBIZ-5198: ------------------------------------ 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