From: "Adrian Crum" <adrian.c...@sandglass-software.com> > The real request duration is meaningless. If a garbage collection occurs > during the request, the measurement will be artificially high. That's > the whole point of the smoothing - it factors out transient performance > differences. > > Please don't break the design. If you don't like the way it works, then > create your own version by extending it.
To keep things clear. The curent design is good for services but not for requests: it does not measure the time passed by the event but the whole request. I believe much users would be interested by the 1st. Jacques > -Adrian > > On 5/17/2013 4:41 PM, Jacques Le Roux wrote: >> What I wanted to add by >> >>> Just thinking I did not use the >> was that I did not use the moving average (I forgot to remove this part >> after). >> Actually I had no needs for it and it's already covered by >> recordServiceRate() anyway. >> >> The pb with current position of recordServiceRate() in RequestHandler is it >> does not measure the real request event duration. That's what I was >> interested by, and I believe much users. Having a moving average is >> secondary for me. >> >> Jacques >> >> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >>> 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/ >
