08 Oct 2021 08:55 AM - last edited on 11 Oct 2021 09:08 AM by MaciejNeumann
Hello everyone,
As far as I know, Dynatrace currently does not have a view with "Start time" as the starting point. The request trend graphs I have seen are all generated with "End time" as the reference point.
Now, when my client wants to know the information of "how many requests are entering at a certain moment at the same time", my thought is that it seems that it is only necessary to count according to the start time of each request, but I tried it, dynatrace It seems that there is no view or report in this area, so I would like to ask you, if there is a solution in this regard?
Thanks in advance
Owen
08 Oct 2021 10:54 AM
What would be the usecase for this exactly? Wouldn't that only really matter if you have services with a very low load and very long running purepaths that vary a lot in duration at the same time?
Assuming that your transactions all take around the same time and the load is equally distributed, wouldn't the amount of transactions per minute by start time be the same as by completed time?
08 Oct 2021 02:54 PM
Isn’t this a case of ‘Concurrent Requests within a period of x secs’ ?
regardless of when/if the incoming request will/has been processed?
11 Oct 2021 11:35 AM
@owen_chendoes have a point here, and I have seen it happen a lot of times: a very big influx of requests, where the first ones are quickly served, but than the remaining queue up for a very long time...
Despite the fact that Dynatrace registers the start time (which most of logs don't), it might be a challenge to get the information wanted...
14 Oct 2021 10:15 AM
Yes, my client wants to know whether the service becomes slow because of a large number of requests coming in at the same time. But it seems impossible to provide such a view from Dynatrace?
20 Oct 2021 08:29 AM
In that case you maybe want to look into other metrics - depending on technology - like worker threads, worker processes, thread pools etc. typically this correlates quite well as an indicator if the high number of requests are the reason for slowdowns (e.g. thread congestion, resource bottlenecks, syncs, etc.)