JBoss Datasources Test

A Datasource is a Java Naming and Directory Interface (JNDI) object used to obtain a connection from a connection pool to a database. When connecting to a data source, JBoss Enterprise Application Platform must allocate resources and de-allocate resources for every connection. This is quite expensive in terms of time and system resources. Connection pooling reduces the cost of data source connections by creating a number ("pool") of data source connections available to be shared by applications. Pooling data source connections is much more efficient than allocating and de-allocating resources on demand. Often, administrators may find it tedious to analyze how well connections from a connection pool have been utilized by the datasource and how efficiently the datasource has been channelizing the connections. This is where the JBoss Datasource Test helps! This test monitors the datasources and reports the following:

  • The number of connections that are currently available and the number of active connections;
  • The number of connections that were created and destroyed using this datasource;
  • The time taken to create a connection on this datasource and the maximum time taken for creating a connection;
  • How many connections are available in a connection pool and how well the connections of a connection pool are utilized?
  • The prepared statement cache size and the number of prepared statements added
  • How many times prepared statements are accessed and how well the prepared statement cache caters to the requests for accessing the prepared statements?

Target of the test : A WildFly JBoss server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each datasource of the target WildFly JBoss that is to be monitored

Configurable parameters for the test
  1. TEST PERIOD - How often should the test be executed
  2. Host – The host for which the test is to be configured
  3. port– The port at which the specified HOSTlistens. By default, this is 9990.
  4. SSLIf the WildFly JBoss server being monitored is an SSL-enabled server, then set the sslflag to Yes. If not, then set the sslflag to No.
  5. IS JBOSS RUNNING IN DOMAIN MODE?– Specify whether the server to be monitored is currently running in DOMAIN MODE or not. By default, this flag is set to No which implies that the server is currently running in STANDALONE MODE. If you have started the target JBoss server using the default web profile configuration in domain mode i.e, if you have executed the ./domain.sh command from the <JBoss_INSTALL_DIR>/bin directory, then specify Yes against this flag.
  6. JBOSS HOST NAME – Specify whether the target server to be monitored is a master or a slave in a JBoss cluster. By default, none will be specified here which implies that the target JBoss server is a standalone server. Refer to Identifying the host name and server instance name of the WildFly JBoss server running in Domain mode to know how to identify whether the target server is a master or slave in your environment.
  7. JBOSS SERVER INSTANCE NAME– Specify the name of the server instance that is to be monitored. By default, none will be specified here. Refer to Identifying the host name and server instance name of the WildFly JBoss server running in Domain mode to identify the name of the server instance that is to be monitored. 
  8. MANAGEMENT USER and MANAGEMENT PASSWORD– Specify the credentials of the user who is authorized to access the management console of the target JBoss server. To create a new user, refer to Creating a new management user in the WildFly JBoss server of this document.
  9. confirm password– Confirm the MANAGEMENT PASSWORD by retyping it here.

 

Measures made by the test:
Measurement Description Measurement Unit Interpretation

Active count:

Indicates the number of active connections through this datasource.

 

Number

A high value is desired for this measure.

Available count:

Indicates the number of connections that are currently available for use in this datasource.

Number

A low value for this measure indicates that adequate connections are not available in the datasource.

Average blocking time:

Indicates the average time spent blocking a connection during the last measurement period.

Secs

 

Average creation time:

Indicates the average time spent for creating a physical connection during the last measurement period.

Secs

Comparing the value of this measure across the datasources will reveal the datasource that is the slowest when creating a physical connection.

Created count:

Indicates the number of connections that were created using this datasource.

Number

 

Destroyed count:

Indicates the number of connections that were destroyed in this datasource since the start of the server.

Number

 

Max creation time:

Indicates the maximum time taken to create a connection in this datasource.

Secs

Compare the value across the datasources to identify the datasource that is taking too long to create a connection i.e., you can identify the datasource that is the slowest.

Max used count:

Indicates the maximum number of connections that were used in this datasource.

Number

 

Max wait time:

Indicates the maximum time a user had to wait for a connection through this datasource.

Secs

A low value is desired for this measure. An abnormally high value or a sudden increase in the value of this measure is a cause of concern which requires further investigation.

Timed out:

Indicates the time taken for a connection to time out.

Mins

Normally, a connection would time out if it has been waiting in the queue for a longer time.

Total blocking time:

Indicates the total time taken for a connection to fail or time out.

Secs

 

Total creation time:

Indicates the time taken to create a connection through this datasource.

Secs

A low value is desired for this measure.

Maximum pool size:

Indicates the maximum number of connections that can be handled by the connection pool of this datasource.

Number

The max-pool-size parameter defines the maximum size of the connection pool. This parameter is more important because it limits the number of active connections to the datasource and thus the concurrent activity on the data source. If this value is set too low it's likely that the platform's hardware resources will be underutilized.

Minimum pool size:

Indicates the minimum number of connections that the connection pool of this datasource can contain.

Number

The min-pool-size data source parameter defines the minimum size of the connection pool. The default minimum is zero connections, so if a minimum pool size is not specified, no connections will be created in the connection pool when the platform starts. As data source transactions occur, connections will be requested but because the pool defaults to zero on start up, none will be available. The connection pool examines the minimum and maximum parameters, creates connections and places them in the pool. Users of any affected application will experience a delay while this occurs. During periods of inactivity the connection pool will shrink, possibly to the minimum value, and later when transactions occur application performance will again suffer.

PreparedStatement cache size:

Indicates the number of prepared statements per connection to be kept open and reused in subsequent requests.

Number

When using the JPA annotations for queries, the result is prepared statements that will be executed against the database. Prepared statements have two phases for execution: preparation of the statement, and execution of the statement. Statement preparation involves significant CPU load so to improve throughput prepared statements can be cached. Statements can be cached either via the JDBC driver or configuration of the data source.

To enable caching of prepared statement, add the following two lines to the data source configuration file, a file with the pattern *-ds.xml (where the * is usually your database, such as oracle, mysql, db2, etc.) in the directory: JBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy. Note that the minimal configuration does not support data sources.

<prepared-statement-cache-size>100</prepared-statement-cache-size>

<shared-prepared-statements>true</shared-prepared-statements>

The first line enables the prepared statement cache and sets the size of the cache. This should be large enough to hold all the prepared statements across any and all deployed applications using this particular data source (multiple data sources can be configured). The second line states that if two requests are executed in the same transaction the prepared statement cache should return the same statement. This will avoid the use of CPU cycles in preparing the same statements over and over again, increasing throughput and decreasing response times. The actual improvement will vary according to specific circumstances but is well worth the effort.

PreparedStatement cache access count:

Indicates the number of times the prepared statement cache was accessed.

Number

 

PreparedStatement cache add count:

Indicates the number of new prepared statements added i.e., cached in the prepared statement cache.

Number

 

PreparedStatement cache current size:

Indicates the number of prepared statements that are currently available in the cache.

Number

If the value of this measure is close to the PreparedStatement cache size measure, then it indicates that the prepared statement cache is almost running out of space.

PreparedStatement cache delete count:

Indicates the number of prepared statements that are deleted from the prepared statement cache.

Number

 

PreparedStatement cache hit count:

Indicates the number of times the statement was accessed from the prepared statement cache.

Number

A high value is desired for this measure.

PreparedStatement cache miss count:

Indicates the number of times a request for a statement was not serviced from the prepared statement cache.

Number

A high value for this measure is a cause of concern.