I have a problematic PP whose root cause is excessive DB queries for 3 separate tables, according to the PP tree for it. For example, it has over 2500 executions for EACH table (2500 x SELECT * FROM ...). The problem is, I would like to capture such individual statement counts as it appears in PP tree.
I have given up on the DB Count measure, no matter what I try it doesn't seem to give me proper results. In that same time frame the count was 34, when it should be in the thousands, as noted above. For reference, I added DB Count to the BT as a result, using 'sum' aggregate. Then in the chart, I add it using 'sum' aggregate again.
Any advice on how to capture the DB summary correctly?
Answer by Roy L. ·
Sorry, I should add I am trying NOT to go the instrument route, as that could lead to bad performance, given the number of statement executions that happen!
Roy,
no need to instrument anything for Database Statements, the JDBC sensor will exctly capture this information for you already.
You are probably mixing the (avg) DB count that you will see per default on a BT that you have added the DB Count as a result measure on.
Likely you have done the following:
What you will need is an additional filter on the BT to filter out those transactions that have more than X DB statements.
In the costco PreProd Profile check the 'DB Statement Requests' BT this is exactly doing what you are looking for, for PPs with more than 100 statements.
Reinhard
Thanks Reinhard,
Yes I used 'DB Statement Requests' BT as the prototype which to copy from. But one key difference: you're right I don't have a DB filter. Reason is, I still want to capture non-DB requests in this BT (due to caching layer not all requests will hit the DB). Does this skew the results of the DB Count measure? I think then I must duplicate this BT and basically add the additional filter for DB Count, or is there a more elegant solution to capture PP's with or without DB activity in a single BT?
JANUARY 15, 3:00 PM GMT / 10:00 AM ET