Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.
AppDynamics customers and established members should click the sign in button to authenticate.
Refer the below screenshot. If I interpret this graph correctly, the time displayed on the connection between two nodes represents the average response time of that remote network call (network latency + execution time in the downstream node). For example, wso2.esb -> wso2.dss connection says 112 calls/min, 0ms and it's a web service calls. Any idea why the JDBC and Web Service calls' average response time is 0 ms? Similarly why the JDBC calls says it takes only 0 ms? Or this time represents network latency only?
1. Any idea why the JDBC and Web Service calls' average response time is 0 ms? Similarly why the JDBC calls says it takes only 0 ms?
- Average response time ‘0 ms’ reporting is because on average the response over an hour < 1 ms which is reported as zero.
2. what's the response time graph at the bottom of this flowmap dashboard represents?
- It represents the average response time of the application ci-cd-as-a-service-prod.
Thanks for the response, but it doesn't seem to be correct.
If you see the wso2.gateway to wso2.esb connection, it says 0 ms as the response time, but if you can see wso2.esb node's average processing time, it says 1 sec. How can be the average response time 0 ms?These two metrics are condtracting.
Similarly, given that the wso2.esb node's average processing time is 1 sec, how can be the average response time of ci-cd-as-a-service-prod app can be less than that, not even close to 1 sec?
We could tell for sure with a full transaction snapshot, but it is likely that the wso2 gateway is implemented asynchronously internally, meaning the backend response time that the agent registers reflects the time taken to send the request downstream.
You could investigate setting up end to end demarcation to measure the response time.
I recommend you work with support via a ticket if you need heklp with this.
Yes, wso2.gateway and wso2.esb are using non-blocking transport. Meaning, they send request to backend, registrer a callback and return immediately, they don't wait for the response. So the time displayed on top of the connection arrow is just including the time wso2.gateway takes to send the request to wso2.esb.
Now the question is, wso2.gateway and wso2.esb both are using the same mediation implementation. If I want to use end to end demarcation using class name and method, both wso2.gateway and wso2.esb will be executing this same class and method in the response path. I'm bit confused which tier appdynamics is going to consider as the logical endpoint, wso2.esb or wso2.gateway?
I've setup end to end demarcation using class name and method. Below is a snapshot, it shows end to end latency as 2.1 sec. Not sure which tier appdynamics considered as the logical endpoint (because the same class/method is executed in two tiers).
I have another question in the metrics presented in this snapshot. It says transaction execution time in wso2.esb is 2 sec (50250%). I'm using a thread sleep for 2 sec in wso2.esb, so execution time within wso2.esb is correctly presented, but what is this 50250% ?
Also why there is no response time displayed on the connecting arrows (wso2.gateway to wso2.esb and wso2.esb to wso2.dss)?