Jboss EAP - Performance Tunning

In IT world the crucial part of the application is the performance and the application is measured, widely accepted based on the performance criteria.  The better performance can be achieved by tune the 3 layers i.e. application, middleware & database layer.

There are multiple check points to measure the performance of all the 3 layers and I will write separate article on performance tuning for application & database layer.

Superior performance comes from the 3 different layers so now I will be going through the performance tuning steps for Jboss EAP which is the middle ware of the system.

Almost 70-80% of the performance problems comes from the application & databases itself and rest comes from the middle ware layer.  We need to pay the attention on five below areas in order to improve the performance which is below:-

1)      Connection Pooling

2)      Thread pooling

3)      Object & component pooling

4)      Logging

5)      Caching

 

Connection Pooling

In order to take the advantage of the robust connection pooling we have to define the connection pooling based on the application requirements. First identify the connections required from the application and then set the pool size accordingly. For ex:- if your application needs 10 connections then set the minimum pool size to 10 and define the higher maximum pool size by 30–40 % i.e. 14. In order to update the pool settings we need to update the data source definitions from the deploy directory.

First monitor the connection pool usage from the JMX console before setting and set it accordingly beco’z the JBoss EAP will maintain the connection request only for 30 sec and after that it will start throwing the exceptions.  Doesn’t worry about maximum connection pool settings as it will be shrink automatically as per the mechanism in JBoss if not utilized.

 Below is the sample from the data source to set the minimum & maximum pool settings:-

<min-pool-size>10</min-pool-size>

<max-pool-size>14</max-pool-size> 

Thread Pooling

JBoss EAP has robust thread pooling mechanism and it’s the important part to tune the application for better performance. Below are the types of the thread pool along with the usage & location to modify the settings.             

             System threads pool   - conf/ jboss-service.xml for JNDI settings 

HTTPd thread pool - deploy/jboss-web-sar/server.xml for making HTTP request 

AJP thread pool - connector section in server.xml for  HTTP requests through mod_jk or mod_cluster

JCA thread pool - in <server>/deploy/jca-jboss-beans.xml  for conjunction with JMS, as JBoss Messaging uses JCA inflow as the integration into EAP   

Object & component pooling

These type of pool settings defined for the EJB object instances and there are 2 types of pools which is below: -

ThreadLocalPool – Stateless & Stateful session beans use this pool which is backed by an InfinitePool with no maximum size.

StrictMaxPool – Message Driven bean use this pool which obeys maximum size and it queues the request if the maximum is reached and time out also if reaches the limit.

In this scenario the system will throw the exception in the mid transaction and you will experience the transaction rollback. We should monitor the StrickMaxPool closely from the JMX console and do the settings accordingly.

               

Logging

We enable logging during the development & testing of the application in order to verify the application process & behaviour. It is fine on the development server with small loads but it can create various bottlenecks if you enable it on the production server. We need to consider the below points in production environment:-

Turn off console logging

Turn down the logging verbosity.

Use asynchronous logging.

Wrap debug log statements by using If(debug Enabled()).

Caching

Cache is the trivial part of tuning the application in order to get the best performance from the application. Caching is an important factor of the application which has high read & write operations. If caching has not configured correctly for high read / write operations then the performance will go down drastically.

We need to modify the persistence.xml in order to cache the EJB entities and also define the cache size and eviction policy in the file

<server>/deploy/cluster/jboss-cache-manager.sar/META-INF/jbosscache-

manager-jboss-beans.xml.