cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

most of the time is spent on Connection Acquisition? Canyou please help me analyze the pure path and identify the root cause?

I am running a java JEE application and in my purepath tree I see 90% of the time is spent on method: Connection Aquisition (API: Connection Pooling).

I understand that it not able to get a connection from the pool and the reason could be Heavy Threading(I see this in the Top Findings).

How will I know what is causing this heavy threading ??

finrelmw.dts


1 REPLY 1

Joe_Hoffman
Dynatrace Leader
Dynatrace Leader

If you're seeing too much Connection acquisition time, I would take a look at the pool size and compare it to the number of busy connections. You'll likely see that you're exhausting your pool and a larger pool is needed. Take a look at the Database dashlet and you'll see the Acquistion Time/Transaction is very large for your finrelmw database, but low for the other two databases. So you know which pool is the problem.

The Database dashlet also shows you the pool size for the finrelmw pool. It is set to only 10. That seems a bit small for your system. I see that you're running 1000-2000 requests/minute.

Also, if you drill into the purepath, and on the Connection Acquisition line, select right-click-> details, you'll note at the bottom of the details dialog that of the 12 acquisitions attempted, 2 failed. You have Statement Aggregation enabled which aggregates all the connection acquisitions together, If you need to see each individually, disable Statement aggregation by modifying the profile-> AgentGroup-> Sensor Configuration-> JDBC Sensor Properties. Be sure to re-enable aggregation when you're done exploring necessary details, as this helps minimize overhead.

The Database Count dashlet can help you determine which JVMs are performing all the DB interaction.

I would not focus so much on the heavy threading, as on the pool size. Increase it to 20 or 30 and see how the system improves. Be sure to coordinate this change with the DBA to ensure the database is prepared to handle the load.