Average response time seems to be not correct (for JDBC and Web Service calls)

[rajkumarr]

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?

[rajkumarr]

Also what's the response time graph at the bottom of this flowmap dashboard represents? End to end latency across all tiers or the latency within the first tier?

[Atyuha.Pal]

Hi Rajkumar,

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.

[rajkumarr]

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?

Regards

Raj

[Peter.Holditch]

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.

Warm regards,
Peter

[rajkumarr]

Hi Peter, 

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?

Regards

Raj

[rajkumarr]

Hi Peter,

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)?

Regrds

Raj