JBoss Performance Tuning

JBoss version	EAP-4.3.0.GA_CP03
Configuration	production

Preface

This advice is primarily on how to tune and/or slim JBossAS. The two concepts are orthogonal in most cases. While reducing idle service threads through slimming won't have a large impact on performance, using less memory and resources may allow you to tune other performance aspects. Of course this does reduce startup time. Furthermore, as a general security concept -- remove services you don't use. We will separate the two categories: slimming and tuning. We start by using the production configuration and trimming from there.
Note for those concerned that this advice will make a technically non-J2EE-compliant instance of JBoss, as removing key J2EE services would cause JBoss to fail the TCK. Most performance tuning/administrative tasks done in real-world installations technically fall in this category.

1. Tune the garbage collector
   
   
   • Set -Xms and -Xmx to the same value - This increase predictability by removing the most important sizing decision from the virtual machine.
   • Use server VM - The server JVM is better suited to longer running applications.
     To enable it simply set the -server option on the command line.
   • Turn off distributed gc - Set it to run every 30 minute at least
     -Dsun.rmi.dgc.client.gcInterval=1800000
     -Dsun.rmi.dgc.server.gcInterval=1800000
     
   • Turn on parallel gc - If you have multiple proessors you can do your garbage collection with multiple threads.
     Use the flag -XX:+UseParallelGC.
     
   • Don't choose an heap larger then 70% of your OS memory
     
   • Tune the Heap ratio - The heap ratio specifies how the amount of the total heap will be partitioned between the
     young and the tenured space. For example, setting -XX:NewRatio=3 means that the ratio between the
     young and tenured generation is 1:3
   • XX:+DisableExplicitGC turn's off explicit garbage collection from java code.
2. Don't use Huge heaps, use a cluster More JVMs/smaller heaps can outperform fewer JVMs/Larger Heaps. So instead of huge heaps, use additional server nodes.
   Set up a JBoss cluster and balance work between nodes.
   
   
3. For Disabling Development mode in JBoss Tomcat. Look for the code below in server/production/deploy/jboss-web.deployer/conf/web.xml
   
   
   
   • development - To disable on access checks for JSP pages compilation set this to false.
   • modificationTestInterval - If development has to be set to true for any reason (such as dynamic generation of JSPs), setting this to a high value will improve performance a lot.
   • checkInterval - If development is false and checkInterval is greater than zero, background compilations are enabled. checkInterval is the time in seconds between checks to see if a JSP page needs to be recompiled. Default is 0. 

   <servlet>
     <servlet-name>jsp</servlet-name>
     <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>

   
   Add the following parameters as required
   
   

   <init-param>
      <param-name>development</param-name>
      <param-value>false</param-value>
   </init-param>  

   
   
4. Generic Database Connection Pool configuration Edit server/production/deploy/oracle-ds.xml
   

   <datasources>
      ....
   
   <!--pooling parameters-->
   <min-pool-size>5</min-pool-size>
   <max-pool-size>100</max-pool-size>
   <blocking-timeout-millis>5000</blocking-timeout-millis> 
   <idle-timeout-minutes>15</idle-timeout-minutes>
   <prepared-statement-cache-size>100</prepared-statement-cache-size>

   
   
   
   
   
   • : this is the number of prepared statements per connection to be kept open and reused in subsequent requests.
   • Disable the connection debugging
   • increase max size of pools to appropriate level
   
   
5. Deployment Scanner - The deployment scanner scanning every 5 seconds eats up cycles especially on systems with a slow filesystem. Edit server/production/conf/jboss-service.xml. change the scan period to larger duration.
   

   <!-- An mbean for hot deployment/undeployment of archives. --> 
   <mbean code="org.jboss.deployment.scanner.URLDeploymentScanner" 

   name="jboss.deployment:type=DeploymentScanner,flavor=URL">
   ...
   <attribute name="ScanPeriod">5000</attribute>
   ...

   </mbean> 

6. Lots of EJB requests ? switch to the PoolInvoker? open server/production/conf/standardjboss.xml and find the following fragment:
   
   

   <invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>

   
   On JBoss should find 4 occurrences of it: stateless-rmi-invoker, clustered-stateless-rmi-invoker, stateful-rmi-invoker,entity-rmi-invoker. Now replace this fragment for desired EJB types:
   
   

   <invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>

   
   
7. If you are using the Pooled Invoker then you may need to change the MaxPoolSize? attribute in pool configuration if required. Edit server/production/conf/jboss-service.xml
   
   

   <mbean code="org.jboss.invocation.pooled.server.PooledInvoker" 
   name="jboss:service=invoker,type=pooled"> 

   <attribute name="NumAcceptThreads">1</attribute>
   <attribute name="MaxPoolSize">300</attribute>
   <attribute name="ClientMaxPoolSize">300</attribute>
   <attribute name="SocketTimeout">60000</attribute>
   <attribute name="ServerBindAddress">${jboss.bind.address}</attribute>
   <attribute name="ServerBindPort">4445</attribute>
   <attribute name="ClientConnectAddress">${jboss.bind.address}</attribute>
   <attribute name="ClientConnectPort">0</attribute>
   <attribute name="EnableTcpNoDelay">false</attribute>
   <depends optional-attribute-name="TransactionManagerService">
   jboss:service=TransactionManager</depends>

   </mbean> 

   
   
8. JBoss Logging
   
   * Enable the logging for file in production enviornment.
   * Disabled for console and the priority to be error.
   
9. Tune the Operating System - Each operating system sets default tuning parameters differently. For Windows platforms, the default settings are usually sufficient. However, the UNIX and Linux operating systems usually need to be tuned appropriately.
   
   * Increase default socket send/receive buffer.
   * Optimize MTU.
   * Use Big Memory Pages.