You can use JMX statistics on the Statistics page in NexJ System Admin Console to evaluate JVM resource utilization, user sessions and load balancing, and database and logical data sources. You can access these key statistics on your NexJ application for individual nodes or a cluster.
Values for statistics are calculated over a sampling period, which is 60 seconds by default. You can modify the sampling period on the Administration node for your NexJ application by changing the Statistics sampling interval attribute value.
JVM resource utilization
The following table identifies statistics that you can use to assess JVM resource usage, such as CPU and memory usage, garbage collection, and live thread count statistics. You can access these statistics on the Java Virtual Machine node.
|
Statistic |
Description |
How to interpret |
|---|---|---|
|
CPU usage (%): mean |
Average CPU utilization over the sampling interval |
Use to determine how busy a particular node is. A constant high value or unusually high number of peaks can indicate an issue with the health of the node. Use in conjunction with Memory Usage, Garbage Collection Time, and User Session statistics. |
|
Garbage collection time (ms): mean |
The average time in milliseconds to complete a garbage collection cycle during the sampling interval |
Track the collection time as a trend. Lengthy garbage collection cycles may negatively impact the overall system performance and indicate that JVM memory configuration requires further tuning. |
|
Memory Usage (%): mean |
Average JVM memory utilization during the sampling interval |
Use to size your heap. |
User sessions and load balancing
The following table identifies statistics that you can use to assess load balancing on nodes and distribution of user sessions in the cluster. You can access these statistics on the SessionManager node.
|
Statistic |
Description |
How to interpret |
|---|---|---|
|
Concurrent request count: max |
The maximum number of HTTP requests that were processed simultaneously during the sampling interval |
Track as a trend. An increase in the request count indicates that the node is under an increased load from the web tier. |
|
Load balancing redirection rate (Hz) |
The rate at which incoming requests are redirected from this node to another node |
An increase in the redirection rate may indicate that the node is under stress and is actively swapping sessions to other nodes in the cluster. |
|
Processing time (ms): mean |
The average time spent by the application to process a request |
An increase in processing time may indicate that the node is busy or that a potential issue exists in the database tier |
|
Session count |
The total number of active user sessions in memory on this node during the sampling interval. By default, the sampling interval is 60 seconds. |
Use to view the distribution of active user sessions across the cluster. If there is a significant imbalance, consider correlating this statistic with JVM CPU and Memory utilization metrics, as session load balancing is affected by the node resource utilization. |
Database and logical data sources
The following table identifies database and logical data sources statistics that you can use to assess the health of database and data source connections. You can access these statistics by navigating to a specific data source under the DataSource node.
|
Statistic |
Description |
How to interpret |
|---|---|---|
|
Active connection count: mean |
The average number of concurrent connections in use during the sampling interval |
Track as a trend. Use as a baseline to size the database connection pool more accurately. |
|
Active connection count: max |
The maximum number of concurrent connections in use during the sampling interval |
Track as a trend. Use to capture spikes in the database connection pool. |
|
Connection availability (%): mean |
The average amount of time a database connection was available to a thread during the sampling interval |
A value of 100% indicates healthy conditions |
|
Connection pool busy wait time (ms): mean |
The average time that a thread has to wait for a database connection to become available |
A value of 0 indicates healthy conditions |
|
Processing time (ms): mean |
The average time taken by the data source to respond to each request |
Track as a trend. A sudden increase in processing time could indicate problems in the database tier. |
Integration layer and channels
The following table identifies statistics that you can use to monitor send and receive times for channel connections. You can access these statistics by navigating to a specific channel under the Channel node and selecting the Receiver or Sender node.
|
Statistic |
Description |
How to interpret |
|---|---|---|
|
Receive time (ms): mean |
The average time taken to process an incoming message |
Track as a trend. Use to detect slowness in the underlying integration logic. |
|
Send time (ms): mean |
For synchronous messages, the average time taken to send an outgoing message and receive a response from a remote system. For asynchronous messages, the average time taken to send an outgoing message to a remote system. |
Track as a trend. Use to detect slowness in the integrated system’s responses. |