Asynchronous Elapsed Time Question
Greetings All,
I am new to asynchronous calls within dT and am having issues correlating all of the elapsed times to the appropriate call outs. I am attaching a session file in which there is one PurePath that takes 185 seconds in duration. I have been able to correlate all of the external calls, however there is one huge gap between ~64 seconds and ~185 seconds that seems to go unaccounted for.
Background on the application
This is new application to dT monitoring and have no instrumented methods other than auto-sensors and there may exist a load balancer between JBOSS and DB tier.
Background on the session
This is a single transaction of a "validation" step made within the end user's web browser.
Please let me know if you have any other questions.
Thanks
Chris Sechler
Christian,
Thanks so much for the research and responses. Since 5.6 will be released soon, this is most likely the route I will take. However, I will consult with my client to see what route they wish to take.
Chris
after some research i found out that there was a bug in dynaTrace 5.5 which affected auto-sensor matching in conjunction with JDBC statement aggregation. this was already fixed some time ago in a fixpack and will also be fixed in the upcoming dynaTrace 5.6 release. so in your case you would have multiple options:
- turn off JDBC statement aggregation to get better auto-sensor data
- wait for 5.6 to be released soon to have this bug fixed
- try out the fixpack
hope this helps
hi Chris,
i guess your question is: what happened between 64 and 185 seconds, right?
so basically this has nothing to do with asynchronous calls at all, because all of this happens on one thread (PMTPPoolID-1-UNBOUNDED-threadID-21 <1910437121>). so what we can say so far is that in these 121 seconds no database access happens, but not what actually really happens.
usually you should get more information by auto-sensors in this scenario, but i guess there's some auto-sensor matching issue on this PurePath. because in the 185s there were 12314 auto-sensor samples captured which would result in one every 15ms. however, this PurePath has a very recurring structure with all the getConnection()s which makes auto-sensor matching really difficult. in 5.6 where we will have connection aggregation as well, the structure of this PurePath will be somewhat simpler.
right now I can talk to R&D and see if we get some more information about your PurePath and keep you posted.
best,
Christian
