19 Feb 2015 09:14 AM - last edited on 21 Dec 2023 10:57 AM by MaciejNeumann
For service requests (i.e. web requests, etc.) what is the maximum time that data is retained for later response time analysis e.g. without enabling the option "Record historical chart data"?
Solved! Go to Solution.
19 Feb 2015 11:55 AM
Hi,
For trial users we store detailed data for a week and for paying customers we store it 2 weeks.
The option you mention only concerns charting data and does not influence response time analysis at all. Charting data is kept virtually forever, but we show at max 30 days compared to the 30 days before that, so 60 total
Best Mike
19 Feb 2015 01:42 PM
Thanks!
I guess my question was partly triggered by my lack of understanding of how to select a specific time window for response time analysis. I think I just figured that one out 🙂
However, what I'm still missing is the ability to analyze single (e.g. not aggregated) requests as well as a more flexible way to specify a time window (e.g. either by area-selection in the graph or by typing the start date directly).
19 Feb 2015 02:36 PM
Enrico,
Do you mean you want to analyze a specific URL? you can do that by just clicking on the url in the list on the bottom and analyzing the response time from there.
We currently do not allow to choose a timeframe for normal analysis, we might in the future.
For problems we automatically select the appropriate timeframe to show the cause of the problem.
19 Feb 2015 03:56 PM
No, I meant analyzing a single, specific request. As I understand it currently it is only possible to analyze a minimum time frame of 30 minutes, therefore all requests occurring within that time will be aggregated. I imagine that sometimes even filtering by the 10% slowest requests within that time frame will not be sufficient in order to pinpoint the root cause of a problem occurring at a specific time, i.e. when there are multiple, independent root causes which create response time issues... I admit this might be a somewhat hypothetical scenario but I've seen this happening in the past (rarely, but still).