From: "Adrian Crum" <adrian.c...@sandglass-software.com> > There was no need to change the Metrics code. If you don't want > smoothing, then just set the smoothing factor to 1. This is explained in > the schema.
Yes I tried that. But it did not work for my need. See where I put the requestMap.metrics.recordRequestRate() call. And since I wanted to check a lot of requests I did not want to add the burden of putting smoothing="1" on each Also I did not need a moving average, so I put the simplest code you would want. It can be still overriden if needed... It's now all about documenting the feature I believe Jacques > Also, please don't put request-specific code in Metrics - that breaks > the abstraction. > > -Adrian > > On 5/17/2013 3:30 PM, Jacques Le Roux wrote: >> Hi Adrian, >> >> At r1483822 I have improved it a bit for requests. I was more interested in >> chained ones, it works for all. It's a new colums in Metrics page which >> measure the request event duration. Just thinking I did not use the >> I wonder if the use of recordServiceRate() in doRequest() makes sense. Let >> me know if you think we should adapt it for the threshold functionnality >> using the event duration of it's it fine as is. >> >> Also let me know if you want me to create the wiki page when we will be done. >> >> Cheers >> >> Jacques >> >> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>> Anything you can do to improve the implementation will be appreciated. >>> Sorry I haven't had more time to document it. >>> >>> -Adrian >>> >>> On 4/19/2013 12:01 PM, Jacques Le Roux wrote: >>>> OK, I guess the smoothing factor explains the tiny differences for services >>>> But for chained requests it makes no sense. >>>> The metrics report ten more than in log. >>>> I will have a look because it's a fine tool for chained requests duration >>>> which are not availabe in the stats feature >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> Adrian Crum wrote: >>>>> Keep in mind the metrics provide a moving average. Also, there is a >>>>> smoothing factor that can affect the value. >>>>> >>>>> The smoothing factor is important. Let's say you are using a monitoring >>>>> tool to monitor a particular request. If that request has a very brief >>>>> increase in response time, you don't want to be alerted. Instead, you >>>>> want to know when the increase in response time is sustained over a >>>>> period of time. So, the smoothing factor helps prevent "false positives" >>>>> in a way. >>>>> >>>>> Another scenario: You have an eCommerce site and you put a metric on the >>>>> store's landing page and you configure it with a threshold value and an >>>>> alternate view - one that doesn't include a shopping cart. Normally, >>>>> customers land on the normal page that includes a shopping cart. But a >>>>> new promotion causes customers to swamp the server and the shopping >>>>> experience degrades. The metric will smooth the response time values so >>>>> the alternate (non-shopping cart) landing page is not offered too soon. >>>>> But if the server is swamped for an extended period, then new visitors >>>>> will get the alternate page and be able to browse the site without being >>>>> able to order anything. As the request load decreases, the metric will >>>>> smooth the response times so the alternate landing page is not removed >>>>> too soon. When the landing page response time drops below the configured >>>>> threshold, all visitors will receive the normal shopping experience. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> On 4/19/2013 10:53 AM, Jacques Le Roux wrote: >>>>>> Actually r1361725 was also needed for services metrics to work. >>>>>> For services I get slightly higher results than in log. >>>>>> It's more consistent than for chained requests which are plain false. >>>>>> I did not get a chance to look at code yet... >>>>>> >>>>>> Jacques >>>>>> >>>>>> Jacques Le Roux wrote: >>>>>>> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >>>>>>>> Thanks Adrian, >>>>>>>> >>>>>>>> Yes I saw the threshold idea in Java comments >>>>>>>> >>>>>>>> Looks like an interesting tool >>>>>>>> BTW for the other statistics (I never used it), do you know if chained >>>>>>>> requests are taken into account? >>>>>>> Hi Adrian, >>>>>>> >>>>>>> I can answer now that chained requests are not taken into account by >>>>>>> the Statistics feature. >>>>>>> >>>>>>> I also noticed something weird in Metrics feature. The total duration >>>>>>> of the chained requests and the duration of the initial >>>>>>> calling request don't match And when I compare durations in log with >>>>>>> those in Metrics I find those in metrics much higher in >>>>>>> some cases, and always higher. >>>>>>> >>>>>>> Do I misinterpret them? Did you use/check this feature for chained >>>>>>> requests? >>>>>>> >>>>>>> Maybe I should wait your wiki page? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>>> Still, can you confirm only if 1361722 and 1361724 the only commits? I >>>>>>>> guess there is no Jira? >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>>>>> I will create a Wiki page this weekend. >>>>>>>>> >>>>>>>>> The metric name can be anything - the example has a URL: prefix to >>>>>>>>> help >>>>>>>>> distinguish request metrics from service metrics. You can put anything >>>>>>>>> you want there. >>>>>>>>> >>>>>>>>> The request-map can have an additional <response> element - which will >>>>>>>>> direct the servlet to an alternate view if the metric crosses a >>>>>>>>> threshold. I think the JavaDocs explain that. >>>>>>>>> >>>>>>>>> The basic idea is to put metrics in places where you anticipate heavy >>>>>>>>> loads or bottlenecks, then use a third-party reporting/monitoring tool >>>>>>>>> to read the metrics. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> On 4/11/2013 8:36 AM, Jacques Le Roux wrote: >>>>>>>>>> Thanks Atul, >>>>>>>>>> >>>>>>>>>> So you mean you simply need to put a token (like webapp name) before >>>>>>>>>> the request name in this metric name? Did you try it >>>>>>>>>> with another request? >>>>>>>>>> I see it works on trunk demo and OOTB locally. But I can't get it to >>>>>>>>>> work on a custom app I have patched, so maybe I miss >>>>>>>>>> something I will wait Adrian's answer about that >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From: "Atul Vani" <atul.v...@hotwaxmedia.com> >>>>>>>>>>> I think that's just the name, to recognize it among list of several >>>>>>>>>>> others, when there will be lots of them. A certain convention is >>>>>>>>>>> used to >>>>>>>>>>> specify that it is for URL or any service. Then again same names >>>>>>>>>>> request >>>>>>>>>>> mappings can exist in separate webapps, so a leading appname, in >>>>>>>>>>> this case >>>>>>>>>>> 'webtools'. It can be changed to anything. >>>>>>>>>>> >>>>>>>>>>> On Thu, 11 Apr 2013 00:47:26 +0530, Jacques Le Roux >>>>>>>>>>> <jacques.le.r...@les7arts.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Adrian, >>>>>>>>>>>> >>>>>>>>>>>> Let me know if you will, else I might do it... >>>>>>>>>>>> >>>>>>>>>>>> BTW, are 1361722 and 1361724 the only commit? Is there a Jira? >>>>>>>>>>>> >>>>>>>>>>>> Could you explain just a bit more the request syntax, sorry but >>>>>>>>>>>> the OOTB >>>>>>>>>>>> example is a bit confusing. >>>>>>>>>>>> >>>>>>>>>>>> + <request-map uri="ViewMetrics"> >>>>>>>>>>>> + <security https="true" auth="true"/> >>>>>>>>>>>> + <metric name="URL: webtools/ViewMetrics" /><!-- Here for >>>>>>>>>>>> demonstration --> >>>>>>>>>>>> + <response name="success" type="view" value="ViewMetrics"/> >>>>>>>>>>>> + </request-map> >>>>>>>>>>>> >>>>>>>>>>>> What would it be for another than ViewMetrics? >>>>>>>>>>>> I mean why "URL: webtools/ViewMetrics"? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >>>>>>>>>>>>> Great, thanks Adrian! >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe a wiki page using >>>>>>>>>>>>> http://markmail.org/message/x4lzvda66ju6gdg5 >>>>>>>>>>>>> would help to remember the commands? >>>>>>>>>>>>> >>>>>>>>>>>>> Jacques >>>>>>>>>>>>> >>>>>>>>>>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>>>>>>>>>> On 4/7/2013 6:38 PM, Adrian Crum wrote: >>>>>>>>>>>>>>> On 4/7/2013 12:11 PM, Jacques Le Roux wrote: >>>>>>>>>>>>>>>> Jacques Le Roux wrote: >>>>>>>>>>>>>>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>>>>>>>>>>>>>> Have you considered using the metrics feature? >>>>>>>>>>>>>>>>> Ha forgot to ask about it, now I see and remember this thread >>>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>>> will digg in http://markmail.org/message/x4lzvda66ju6gdg5 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Of course, I'd not be against a brief briefing, or a link to >>>>>>>>>>>>>>>>> explain. >>>>>>>>>>>>>>>> What I mostly miss is where are the metrics in webtools? >>>>>>>>>>>>>>> Oops, I forgot to commit that part. I will take care of it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Actually, I did commit it: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://localhost:8443/webtools/control/ViewMetrics >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >
