We've been using analytics to capture load times and other information about our website for about a year now. We've noticed that we occasionally see large spikes in the 'Average' trend line as reported by Telerik. After some analysis, we've realized that the days with these large spikes are directly related to excessively large timings. For example, we might have 1000 timings for a particular day, 999 of them are between 1 second and 30 seconds, and then the remaining one reports a time of an hour and forty three minutes.
Our database would fail after five minutes, so I don't believe it's a valid timing; but I also realize that these numbers are being captured via client-side JS and there are some potential issues.
The problem that I'm having is that, once captured, it destroys the average for the day. We average ~2.5 seconds on most days, but then will have a day with a 9 second average; but by altering the ranges and viewing the data different ways, I'm able to see that it is only one timing that took well over an hour, that is skewing it. Even if create a range that is > 30 - Max and uncheck it; while it does correct the reported average, it does not change the appearance of the average line.
* Is this a known issue with Telerik? We only experience it in our Javascript timings.
* Is there any recommended way we can ignore timings greater than some value?
2 Answers, 1 is accepted
This is the first time someone is reporting us a similar issue. The way our SDK measures time is by storing the result of a "new Date()" call into a dictionary when you use Monitor.TrackFeatureStart and when you use Monitor.TrackFeatureStop we make the time difference with the current time. While not completely impossible, it is highly unlikely that there's an issue with this algorithm.
So basically it will depend on which browser events you are subscribing to in order to perform those 2 method calls, and how are those events supported and implemented in the various browsers and operating systems.
Currently it is not possible to filter out such anomalies on the server, but what we may suggest you is to perform a parallel measurement of the elapsed time between the two events in your application and if your measurement is above the accepted limit, use Monitor.TrackFeatureCancel instead of Monitor.TrackFeatureStop to prevent this value reaching our backend.
Regards,
Darin
Progress Telerik
Rank 1
Thanks Darin,
I agree, I don't see any problem with the calculation logic in the EqatecMonitor.min.js file and it really is quite rare (maybe we have a user who is fond of adding breakpoints and visiting the page with the developer tools open?).
Your suggestion is the path I've taken. We'll call the cancel method if the timing is greater than our largest expected time. Hopefully this will clear up our issue.
Thanks