01 Apr 2018 10:38 AM - last edited on 24 Aug 2021 06:40 AM by Karolina_Linda
I have confusion in understanding what is service client side response.
1. Is it the time taken at network layer? OR
2. Is it the time taken for downloading client side resources like js, css , images etc. OR
3. Is it the time taken by the caller of that request ?
In the chart below I am referring to light blue bar.
4. How should I proceed with analyzing the root cause of client side response time?
Solved! Go to Solution.
In this context the client and server terms are referring to client and server "services." It is helping to understand and visualize where time is spent in your detected services and database services (database calls). In a PurePath there will be links between services as one service calls another or calls a database.
For a given service the time spent before returning within itself is the client-side service time whereas the time spent in the services or databases they call (and the services those services call) are attributed to server-side service time.
So if Service A calls Service B which calls Service C before returning something for Service A, for Service A the time spent in the code of Service A is it's client-side service time and the time spent in Service's B and C is the the server-side service time since Service A is the client-side service in that interaction.
Great answer and thanks! Is there any plan to include this in the documentation soon?
I can forward a link of this thread to the team that handles documentation for review.
Hi @James K.,
Thank you for the answer, but I am still not sure if this right definition for client-side response time.
For example, if we have Service A that calls Service B1 and Service B2 like on the screenshot:
In this case, the client-side response time for Service B1 is 14.7ms:
Sorry for bothering you, just wanted to be sure about this, because it is important for performance analysis.
I spent some time thinking this through and I am trying to confirm some of this but let me put this out there as it makes sense based on the the more I look into examples.
So in your example, the client side response time is 14.7 ms because from when the client service A called B1 the response time of B1 was 14.7 ms, but B1 only saw it should execute after a number of ms and from when it actually started to when it finished was only 9.2 ms - the rest of the time in the light blue bar would be something else upstream. A self time of 2.7 ms says to me that is how much time was actually spent in the code for B1 itself (the rest looks like DB activity).
Does that make sense? Thanks for noting something didn't seem correct.
Thank you for quick response.
I think I got the your point about client-side response time.
The only thing that is still a little bit unclear to me, is relationship between client-side and server-side response time. It is logical to me that client-side includes server-side response time.
So, from my example 9.2 ms is included into 14.7 ms, and there is 14.7-9.2=5.5 ms lost somewhere (traversing the network or something like that).
But if you look at the chart from my example, there is some inconsistency there:
So, based on topics above, client-side time will finish before server-side time which is strange to me? In this case client-side time should finish at the same time like server-side ~ 10:30:37.626 (or 18 ms from start), so duration of client-side response time should be ~17 ms.
Do you see some wrong logic here, maybe I missed something?
I think I see what you mean and I can't explain that - first thought is that with such small levels if there's any rounding maybe it gets funky. Regardless, I'm gonna look into it more as I want to understand it better as well.
Thanks for your help. I will also try to find the answer for this.
Just got some possible explanations - if these services are on different hosts it could be as simple as a time sync issue. The start times you see there will be server time and with such low times it's possible that is if they are slightly different you can see anomalies like that.
If the services are on the same host though the recommendation I got was to open a ticket so it can be investigated. Regardless, I'm pretty confident the general explanation I provided is correct but will update if I find anything new.
Here I have interesting PurePath with big client-side response time between services, which are running on one host on containers. I cannot explain such big numbers. Can anybody help me please?
Please see exemplary explanation shown here https://www.dynatrace.com/support/help/how-to-use-dynatrace/services-and-transactions/analysis/purep...
"According to the example above, most of the time of this particular request was spent on the client side of the
getLoyaltyStatus web service call. As indicated by the colors of the bars in the chart, the time was not spent on the server side of this web service but rather on the client side. If we were to investigate this call further, we would find underlying network latency. "
I can understand if client-side RT is before Server-side RT as @James K. wrote here
So any client-side time at the beginning is time from when the client service called the service to when the service began executing
But I cannot understand then client-side RT is at the end just right after server-side RT and the services are running on the same host in docker containers
I saw that Purepath had an example of this, Service A's (the first Tomcat's service） "Client-side response time" had 20.3 seconds, but the "self-time" was only 80.6ms.
I looked at this thread and knew that 20.3 seconds was spent in "Service A", but overall I still don't know where to check "Serivce A" to explain or improve the response time.
Does anyone have a similar experience that can help me?
@owen_chen it really depends on what the service A and the called service. The difference represents the time spent between the time service A initiated the request and the time the request processing on called service was started.
It can be basically anything. Be also sure to check the code level tab here and also verify if you have all application components between calling and called service covered by OneAgent.