From: "Adrian Crum" <adrian.c...@sandglass-software.com> > What you believe users want and what the feature was designed to do seem > to be entirely different. > > The metric is intended to measure the entire request. If you want > something different, then feel free to modify your local copy.
I believe some users will be interested by what I added. I did not remove anything! Jacques > -Adrian > > On 5/17/2013 5:25 PM, Jacques Le Roux wrote: >> 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/ >
