Jazzmon, first run results, questions
so, I made my first run today, default time span (60 minutes)..
JTS and CCM servers, I am not a jazzadmin..
so the elapsed time is 7200 seconds (2 runs @ 60*60)
in the CCM output I have a few items that have total elapsed times >7200 seconds..
(seconds, service, count, deviation)
15901 com.ibm.team.repository.common.internal.IFeedService.GET 60909 .444
13278 com.ibm.team.repository.common.service.IQueryService.queryitems 154683 .116
10371 com.ibm.team.scm.common.IVersionedContentService.GET 2211228 .059
how does that happen?
Sam
JTS and CCM servers, I am not a jazzadmin..
so the elapsed time is 7200 seconds (2 runs @ 60*60)
in the CCM output I have a few items that have total elapsed times >7200 seconds..
(seconds, service, count, deviation)
15901 com.ibm.team.repository.common.internal.IFeedService.GET 60909 .444
13278 com.ibm.team.repository.common.service.IQueryService.queryitems 154683 .116
10371 com.ibm.team.scm.common.IVersionedContentService.GET 2211228 .059
how does that happen?
Sam
Accepted answer
The raw web service counter reports have sets of data in the form:
where data is recorded since startup as you mentioned. The JazzMon trend tables that are produced for counts and totals compute the deltas in between samples so those will be on a per hour or per sample-time basis. The averages are used directly without being recomputed so they reflect the longer history of usage.
cnt | avg | max | min | dev | tot |
where data is recorded since startup as you mentioned. The JazzMon trend tables that are produced for counts and totals compute the deltas in between samples so those will be on a per hour or per sample-time basis. The averages are used directly without being recomputed so they reflect the longer history of usage.
7 other answers
JazzMon 1.3.0 has just been released and computes interval averages now based on the total time and counts per interval instead of using the server-reported cumulative average. This provides a much more dynamic picture of the actual average response times encountered.
JazzMon 1.3.0 also now supports comma separated file format and adds formulas on each line to compute totals, averages, max values, etc to serve as convenient sort keys.
JazzMon 1.3.0 also now supports comma separated file format and adds formulas on each line to compute totals, averages, max values, etc to serve as convenient sort keys.
thank you, thank you, thank you..!! this improves the data immensely
I have a question on the new columns of data
I have a custom excel macro that combines a few tables, shows important web server calls, etc..
when the 1st days samples are reported, my min/average/max is the same as the jazzmon average
we then accumulate and add a second day.. now our averages no longer match..
so, I 'think' the new added columns reflect the total time reported
we report daily on 15 min samples, 96 samples a day, then reset and start over each week.
I have a question on the new columns of data
I have a custom excel macro that combines a few tables, shows important web server calls, etc..
when the 1st days samples are reported, my min/average/max is the same as the jazzmon average
we then accumulate and add a second day.. now our averages no longer match..
so, I 'think' the new added columns reflect the total time reported
we report daily on 15 min samples, 96 samples a day, then reset and start over each week.
The new formula columns are pretty simple minded which means in some situations they may not always be what you are looking for. They just use embedded Excel formulas so you can see directly how they are computing their results and they only reference the data columns in the current spreadsheet.
The service_etAvg.csv file now shows interval averages computed by taking the total time spent in each interval and dividing it by the total counts for that interval rather than the original. I am not sure how the first and second day work with your reporting but the current data computed average may be causing the disagreement.
The totals column just provides a total of the interval averages which helps highlight "interesting" services taking the largest amounts of time but a total of averages or an average of averages aren't always meaningful in themselves.
The service_etAvg.csv file now shows interval averages computed by taking the total time spent in each interval and dividing it by the total counts for that interval rather than the original. I am not sure how the first and second day work with your reporting but the current data computed average may be causing the disagreement.
The totals column just provides a total of the interval averages which helps highlight "interesting" services taking the largest amounts of time but a total of averages or an average of averages aren't always meaningful in themselves.
>They just use embedded Excel formulas so you can see directly how they are computing their results and they only reference the data columns in the current spreadsheet.
this is the point I was making..
OUR spreadsheet (this morning, day 7) has data columns D thru XL. which is 7 days of 96 samples per day..
the LAST day is only columns US-XL..
ps there are no algorithms in the xls file.. only the final data values.
so, my comment was, you are reporting on accumulated data, which will flatten the peaks.
in addition I just discovered an anomaly in my reporting that also experience and might want to correct..
at least as far as response time is reported.
if there are many sample periods where NO activity on that web service is recorded, but you use them for the calculated average, then the real average will be incorrect.
for response time, you should only use periods where there WAS activity.. I think this is what causes the baseline numbers to be so low in some cases.. (iVersionedContentGet at 6ms average.. i really don't believe that)
on the jazz.net system, I would expect an isolated build time, and a lot of quiet.. so this would skew the numbers.
on my saturday report (friday night to saturday morning) 1/3 of the samples is with no builds..
using all samples the avg response time is reported at 32ms.. (there are only two periods where response time was below 32, and both were 28ms).. using just the sample times where there was activity, the average is 66ms
much more accurate..
and by the way, Great tool, very helpful. !!! thank you
this is the point I was making..
OUR spreadsheet (this morning, day 7) has data columns D thru XL. which is 7 days of 96 samples per day..
the LAST day is only columns US-XL..
ps there are no algorithms in the xls file.. only the final data values.
so, my comment was, you are reporting on accumulated data, which will flatten the peaks.
in addition I just discovered an anomaly in my reporting that also experience and might want to correct..
at least as far as response time is reported.
if there are many sample periods where NO activity on that web service is recorded, but you use them for the calculated average, then the real average will be incorrect.
for response time, you should only use periods where there WAS activity.. I think this is what causes the baseline numbers to be so low in some cases.. (iVersionedContentGet at 6ms average.. i really don't believe that)
on the jazz.net system, I would expect an isolated build time, and a lot of quiet.. so this would skew the numbers.
on my saturday report (friday night to saturday morning) 1/3 of the samples is with no builds..
using all samples the avg response time is reported at 32ms.. (there are only two periods where response time was below 32, and both were 28ms).. using just the sample times where there was activity, the average is 66ms
much more accurate..
and by the way, Great tool, very helpful. !!! thank you
Ok so I understand your point better that the formula that computes the average should not include the zero interval averages because that waters down what is otherwise now more useful/accurate values in the individual intervals to produce an inaccurate average of averages value. I will give some thought to how to improve that situation.
Appreciate your input as always.
Appreciate your input as always.
JazzMon 1.3.1 has just been released to address the issue that you raised with mis-computing the overall average response time by including empty intervals (Workitem JazzMon average of interval averages is inaccurate because it includes intervals with no activity to compute average (236829)). Please see the JazzMon wiki for the latest bits.
We now compute the overall averaged based on the total elapsed time spent on each web service divided by the total number of counts during the period being analyzed. In addition the average response time tables (*_etAvg) now include two new columns - TotalTime and TotalCounts - used in this computation. These new columns provide additional sort columns to allow filtering out or hiding low frequency operations when working with average response times.
As always, newer versions of JazzMon can be used to reanalyze existing data.
We now compute the overall averaged based on the total elapsed time spent on each web service divided by the total number of counts during the period being analyzed. In addition the average response time tables (*_etAvg) now include two new columns - TotalTime and TotalCounts - used in this computation. These new columns provide additional sort columns to allow filtering out or hiding low frequency operations when working with average response times.
As always, newer versions of JazzMon can be used to reanalyze existing data.
Comments
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Aug 07 '12, 8:12 a.m.In your question title, the goal is to produce a title that summarizes the specific question. So something like "Why is jazzmon saying an item is taking longer than the elapsed time of my jazzmon run?". As a general clue, if you don't have a question mark at the end of your question title, it probably isn't a good question title.
sam detweiler
Aug 07 '12, 8:25 a.m.thanks.. I stared with a lot more questions, then just got overwhelmed.. I usually try to focus in. I don't generally use question marks in forum titles because the audience is so wide, and english syntax is not always the primary.