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?
Perfect, that's great news. Figured this was a side-affect of the (nicely done) statement aggregation functionality.
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
