Purepath Length Explosion in Production
We have some very data intensive applications that within a single business transaction will make upwards of 6-10,000 database calls. We turned on SQL Statement Aggregation, which reduced the purepath size significantly but we're still hitting 10-15k in production when this occurrs. I'll make no comment on a code base that does this, however ;^).
However, what we see is the 6k statements, nicely aggregated, and then thousands of entrys of getConnection() calls, which as you can see from the display, isn't particularly meaningful. We could disable it, but I'm not sure that is the right answer, since getConnection() is an area that could potentially have a bad slowdown occur. Thoughts on the best approach here?
Hi Jim
The upcoming Fall Release (dynaTrace 5.6) will have getConnection aggregation as well. This will solve your problem of these long purepaths. Unfortunately there is not a good workaround with 5.5 to get rid of these getconnections without breaking major functionality of our database support.
Andi
Perfect, that's great news. Figured this was a side-affect of the (nicely done) statement aggregation functionality.
Welcome the
Dynatrace Community Forums
Check out the Forum User Guide and Forum Guidelines to learn how to get started.Community Member of the Month
August 2017
Announcing Dynatrace's Community Member of the Month for August 2017, Rick B.! Click here to read more! 