You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Jacques Le Roux (JIRA)" <ji...@apache.org> on 2013/05/23 10:00:22 UTC

[jira] [Closed] (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:all-tabpanel ]

Jacques Le Roux closed OFBIZ-5198.
----------------------------------

    Resolution: Implemented
      Assignee: Jacques Le Roux

Thanks Adrian for the explanation!

Committed at revision: 1485601

I did not implemented a threshold handling for Event because this did not make much sense to me. I believe threshold handling at the Request level is enough. This tough introduces a kind of inconsistency, since you still can add the threshold attribute to the metric element of the event element. So I simply explained in the XML documentation.

We still need to create a wiki page for the Metric, for now the XML embedded will do it.
                
> 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
>            Assignee: Jacques Le Roux
>            Priority: Minor
>             Fix For: SVN trunk
>
>
> *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