Pool statistics

, ,
1

Hi,

I would like to know if there is an issue to get statistics about jdbc pool.

I want those kind of informations :

  • current number of availables connections
  • current number of actives connections
  • average/min/max delay between connection request and connection attribution
  • etc.

I already have trying to use server.jar include in webMethods lib but without any convincing result.

Regards

2

The built-in pub.art.connection:* services might be helpful. They are described in the Built-In Services Reference.

Mark

3

Thanks for your answer, but I think that’s a little “short”.

I need more information like : “how long does an adapter service have to wait before getting a connection ?”

I think I will have to use webMethods java lib but I don’t know which one to use …

4

Two items to consider:

  • It’s not clear that the ART tracks the information you’re after. Given that the pub.art.connection:getConnectionStatistics service doesn’t return that information, it seems quite likely that wait time is not captured.

  • You may indeed be able to use the classes in server.jar or wmart.jar to get what you’re after. I’m sure you’re aware that if you use non-published classes/services you’re not going to get help from wM.

This seems to be a very specific metric you’re trying to capture. What’s the motivation?

5

When you define adapter connections you specify a timeout value after which an exception is thrown if no connections are available. The settings for adapter connections are explained in the documentation for each adapter.

You can get stats on available connections, used connections, fulfilled connection requests since last reset and unfulfilled or “missed” connection requests. However, I don’t think more fine grained information is available from the public API.

What are you trying to accomplish? Are you conducting a performance test or attempting to instrument your integration application for systems management purposes?

Mark

6

I have used wm.art.ns.getAllConnectionMetaData on a few occasions for getting blockTimeout values. Not too sure how heavily I can rely on it though.

7

You can rely on it just fine. I’ve used wm.art.admin.connection:getResourceConfiguration instead.

But boubavic isn’t after the configuration of the pool, but is after run-time statistics. Neither of these services will help with that.

8

thanks for all your answers !

What is my motivation ? I have to run perfomance test and I want to define correctly my pool configuration.

But I also want to develop some tools that I will be able to reuse later…

I already have a tool which give me average run time for each service but jdbc pool is to my point of view a performance limiter…

9

Connection pools in general and JDBC pools specifically (when sized properly) are generally viewed as a technique to improve performance since they allow the overhead of reconnecting to the database server to be avoided. The time to request and receive a connection from a pool is many times faster than reconnecting to a database server over the network.

Sizing the pool too small results in reduced throughput due to connection retries or exceptions thrown due to inadequate connection availability. Sizing the pool too large uses additional thread and memory resources that could otherwise be put to better use.

Sounds like you might be attempting to tune performance too early. Someone here wrote about that once, I think. :slight_smile:

Mark