Monitoring KPIs (Key Performance Indicators) using JBoss JMX-Console
--Mahesh PatilThe JBoss comes with an inbuilt application 'JMX-Console', which basically is a web interface to all the MBeans registered with the JBoss MBean Server. It provides a raw view into the microkernel of the JBoss application server by exposing various methods and attributes of MBeans. During the load testing (Stress testing), this application is very handy to check various KPI's(Key Performance Indicators) to make sure you web application would work fine in Production. So let's see how we can check those KPI's. Ideally I would suggest using some monitoring tool to monitor various KPI's during Stress tests.
Once JBoss has been successfully started, you can locate the JMX console at http://localhost:8080/jmx-console (assuming that JBoss is running on default port number). The parameters and their importance I'm going to discuss are HTTP Threads, HTTP Sessions, No of Database connections in use and JVM Free Memory.
The login policy for JMX-Console is defined in '/conf/login-config.xml' file, and for default configuration, the user credentials are defined in '/conf/props/jmx-console-users.properties' file.
|
|
||
| For production environments, it's recommended to use secure login policy e.g. LDAP based authentication, instead of keeping user credentials in plain text file. | ||
We'll look at few MBeans in order to check our KPI's. I'm assuming that you have already logged in to JMX-Console and can see all MBeans.
BaseModelMBean (Jboss.web):
If you scroll to jboss.web domain name, towards the end of the links you'll see 'name=http-127.0.0.1-8080,type=ThreadPool', the IP address and port number will vary depending on your environment.
On clicking this link, you'll see JMX MBean View, showing various attributes related to HTTP Threads. The maxThreads is an important tuning parameter. This determines the maximum number of simultaneous requests that can be handled by JBoss. To update the value, open 'server.xml' file present under '\jboss-as\server\default\deploy\jboss-web.deployer'. The HTTPConnector looks like:
The attribute currentThreadBusy in JMX MBean View indicates the number of HTTP threads busy at the moment. If you observe (e.g. during stress test) this value is going beyond 80% of maxThreads, then you should consider increasing maxThreads value. If all the Threads are in use, further simultaneous requests will receive "connection refused" errors, until resources are available to process them. The acceptCount attribute of Connector indicates that if simultaneous request exceeds the value of maxThreads, they are stacked up to the configured value of the acceptCount attribute. But I would not count on this, firstly because this will definitely affect the performance, and secondly I've seen during number of stress tests that the currentThreadBusy hovers around 80% of maxThreads before suddenly reaching 100%, and badly affecting performance. Setting maxThreads to very high value can lead to consumption of good chunk of memory, and system will spend too much time context switching. So you make sure that the maxThreads value is set according to your requirements.
Active Sessions: If you go back to Agent View, and under the same domain name
'jboss.web' click on link 'name=localhost,path=/,type=Manager'. Please note, the path value depends
on your application context, the image shown below is for application context test.
You'll see MBean view with various attributes related to HTTP Sessions. All the values are for
the selected path (which is the application context). The attribute activeSessions indicates the
number of active HTTP session at this moment. This tells you how many users are performing some
kind of activity on your site. During stress test, this parameter is useful to find out how
many simultaneous users your web application can support gracefully. Most of the attributes and
operations supported by this MBean are self explanatory and also shows short description.
ManagedConnectionPool(Jboss.jca):
Finally we'll have a look at the connection pooling MBean, ManagedConnectionPool (this is an interface and implementation class is JBossManagedConnectionPool). On Agent View if you scroll to jboss.jca domain name, click on link name=DefaultDS,service=ManagedConnectionPool (The value of name depends on JNDI name of your database pool).
On JMX MBean view page you'll see various attributes such as MinSize, MaxSize, which indicates the minimum and maximum connection pool size of your DataSource.
When it comes to performance tuning your application, the important attribute to look for is MaxConnectionsInUseCount, this indicates the Maximum number of connections in use at one time. You want to make sure that value of this attribute doesn't go beyond 80% of MaxSize otherwise at any point of time during stress tests. The attribute InUseConnectionCount will tell you how many connections are in use at this time.
ServerInfo (Jboss.system):
If you scroll down to jboss.system domain name, you'll see type=ServerInfo.
When you click on that link, you'll see JMX MBean View for MBean ServerInfo. This view lists various attributes exposed by the MBean. You can validate various parameters about the OS and the JVM if you are not sure about. The important one is FreeMemory; this is the amount of free memory available from the allocated Heap (using -Xms and -Xmx). The value keeps going up and down based on the execution of Garbage Collection (GC). While running your stress tests if it's going down very often then it's better to consider resizing of your JVM Memory as number of GCs can affect the performance (e.g. response time) of your application.
Checking the memory pool usage:
The ServerInfo MBean registered under the name jboss.system:type=ServerInfo has been enhanced with
a new operation listMemoryPools(boolean fancy), that presents information about the memory pools
managed by the JVM. Calling the operation with a boolean value of false, produces a listing like shown below.
Make sure that the Perm Gen usage (this is non Heap) is not close to the allocated size
(set using -XX:PermSize and -XX:MaxPermSize) otherwise your application will result into OutOfMemoryError.
