Java Database Connectivity (JDBC) is a standard Java API for interfacing with database and executing SQL statements.
Database is often a performance bottleneck and it is important to monitor carefully from all angles. The counters below are relevant for the JDBC connection pool. They assist in completing the picture of the database behavior under load.
JVMProcessorLoad Displays a snapshot of the load that the VM is placing on all processors in the host computer. If the host contains multiple processors, the value represents a snapshot of the average load.
The value is returned as a double, where 1.0 represents 100% load (no idle time) and 0.0 represents 0% load (pure idle time).
TotalNumberOfThreads Indicates the number of Java threads
(daemon and non-daemon) that are currently running in the VM across all processors.
NumberOfDaemonThreads Indicates the number of daemon Java threads currently running in the VM across all processors.
Counter Description
MBean: weblogic.management.runtime.JDBCDataSourceRuntimeMBean
ActiveConnectionsAverageCount Average number of active connections in this instance of the data source. Active connections are connections in use by an application.
ActiveConnectionsCurrentCount The number of connections currently in use by applications.
Counter Description
ConnectionDelayTime The average amount of time (in milliseconds) that it takes to create a physical connection to the database. The value is calculated as a sum of all the times it took to connect, divided by the total number of connections.
CurrCapacity The current count of JDBC connections
in the connection pool in the data source.
LeakedConnectionCount The number of leaked connections. A leaked connection is a connection that was reserved from the data source but was not returned to the data source by calling close().
NumAvailable The number of database connections
currently available (not in use) in this data source.
NumUnavailable The number of database connections that are currently unavailable (in use or being tested by the system) in this instance of the data source.
PrepStmtCacheHitCount The cumulative, running count of the number of times that statements from the cache were used.
PrepStmtCacheMissCount The number of times that a statement request could not be satisfied with a statement from the cache.
WaitingForConnectionCurrentCount The number of connection requests waiting for a database connection.
Counter Description
JMS
WebLogic JMS is an enterprise-class messaging system that is tightly integrated into the WebLogic Server platform.
The following counters are relevant only when your application uses WebLogic JMS. In such case these counters are very useful in determining whether or not the JMS server is a bottleneck.
Counter Description
MBean: weblogic.management.runtime.JMSRuntimeMBean
ConnectionsCurrentCount The current number of connections to WebLogic Server.
MBean: weblogic.management.runtime.JMSServerRuntimeMBean
BytesCurrentCount The current number of bytes stored on this JMS server. This number does not include the pending bytes.
BytesPageableCurrentCount The total number of bytes in all the messages that are currently available for paging out, and have not yet been paged out. The JMS server attempts to keep this number smaller than the
"MessageBufferSize" parameter.
BytesPendingCount The current number of bytes pending (unacknowledged or uncommitted) stored on this JMS server. Pending bytes are over and above the current number of bytes.
BytesReceivedCount The number of bytes received on this JMS server since the last reset.
DestinationsCurrentCount The current number of destinations for this JMS server.
MessagesCurrentCount The current number of messages stored on this JMS server. This number does not include the pending messages.
MessagesPageableCurrentCount The number of messages that are currently available for paging in this JMS server but have not yet been paged out.
MessagesPendingCount The current number of messages pending (unacknowledged or uncommitted) stored on this JMS server. Pending messages are over and above the current number of messages.
MessagesReceivedCount The number of messages received on this destination since the last reset.
SessionPoolsCurrentCount The current number of session pools instantiated on this JMS server.
Counter Description
JTA
One of WebLogic’s fundamental capabilities is transaction management which provides guarantees that database changes are completed accurately with high integrity.
The following counters are useful when trying to evaluate the workload that the server and application can sustain.
Tip: Evaluate rolled back transactions rates. A rate higher than expected should be investigated by looking at the reason for the rollback, and then correlating it with other counters measured in operating system, application server, database server, and LoadRunner transactions.
Counter Description
MBean: weblogic.management.runtime.JTARuntimeMBean
TransactionTotalCount The total number of transactions processed. This total includes all committed, rolled back, and heuristic transaction completions.
TransactionCommittedTotalCount The number of committed transactions.
TransactionRolledBackTotalCount The number of transactions that were rolled back.
TransactionRolledBackTimeoutTotalCount The number of transactions that were rolled back due to a timeout expiration.
TransactionRolledBackResourceTotalCount The number of transactions that were rolled back due to a resource error.
TransactionRolledBackAppTotalCount The number of transactions that were rolled back due to an application error.
Optimization and Tuning
Optimization and tuning are crucial for resolving performance issues. In most cases application code optimization is required, but sometimes fixing a poorly tuned environment can dramatically improve performance.
This section lists a few possible tuning practices. Some are oriented for the WebLogic application server, while others are general for any application server. There are many other tuning practices that can improve the performance of your application.
Tuning requires a long and iterative process of testing and analysis. Any configuration change requires careful validation. Before applying any of the below practices, validate the relevancy of the configuration to your specific application by understanding the parameters and workload generated against your server.
TransactionRolledBackSystemTotalCount The number of transactions that were rolled back due to an internal system error.
TransactionHeuristicsTotalCount The number of transactions that completed with a heuristic status.
TransactionAbandonedTotalCount The number of transaction that were abandoned.
AverageCommitTime The average amount of time (in
milliseconds) it takes the server to commit a transaction.
ActiveTransactionsTotalCount The total number of active transactions on the server.
Counter Description
Tune Pool Sizes
Tuning EJB, JDBC, and Thread related pools for their appropriate size increases the server's capacity and it performs better. To tune these pools, you monitor the relevant counters mentioned in the previous section, and look for the amount of waits and LoadRunner transaction response time.
Note the optimal response time.
Use the Prepared Statement Cache
The prepared statement cache keeps compiled SQL statements in memory, thus avoiding a round-trip to the database when the same statement is used later.
JVM Tuning
➤ Examine which collection algorithm fits your application better:
concurrent or parallel.
➤ Determine the optimal heap size.
➤ Monitor your application under peak load.
➤ Analyze how often collection is taking place. Too frequent collections with shrinking free memory size may require application code
optimization.
➤ Analyze how long full GC takes. If takes more than 5 seconds, lower the heap size.
➤ Analyze the average memory footprint. If heap is 85% free after full GC, its size can be lowered.
Execute Queue
Increase the thread count if the queue length and the CPU are under utilized. This better utilizes the CPU.
General
➤ Always serve static content such as HTML pages, images, CSS files, JavaScript files using a Web Server. This will reduce the CPU time spent on the application server machine, leaving more time to process other jobs.