JBoss is one of the few open-source application servers that is gaining a lot of customers/users in recent years. Other noticeable open-source application servers in the market include JOnAS, JFox and the upcoming Apache Geronimo. Since I cannot afford to use BEA WebLogic or IBM Websphere, I have to find something that is affordable and reasonably good in performance. There are also mid-market application servers such as Pramati or RexIP that cost less than the big boys. But a lot of times open-source software is good enough for most practical purposes. The price to pay is of course the need to wade through the source code if problems occur, or spend endless hours checking the mailing list archives or forums for answers to problems. This price to most people or companies, is more bearable.This article focuses on one major areas in deploying web applications on the JBoss application server: performance tuning. There isn’t a lot of consolidated information in this area, and the information presented here is through trial and errors and bits and pieces of information found on the JBoss forums and weblogs of JBoss developers. Comments and corrections are very much welcome. Linux is the platform to run the JBoss application server on.There are a number of things one can do to tune JBoss from its default configuration so that it can perform better. Some of these tips may not work in certain environment.

Rebuild JBoss

The binary package of JBoss is built with debug on. Download the source package and rebuild JBoss with optimize set to on and debug set to off.

Code:

$ tar -xvpjf jboss-3.2.3-src.tar.bz2
$ cd jboss-3.2.3-src/build
$ cp etc/local.properties-production local.properties

Edit local.properties to add the following:

# define today's date
build.number=24042004
# use the standard javac
build.compiler=modern

To avoid headaches, use the Sun’s javac. If you are adventurous, you can also define build.compiler=jikes, although I doubt you will get any significant performance improvement since the current version of jikes (1.20) doesn’t actually support optimizing the bytecode (according to the jikes man page).

Build everything and move the resulting distribution to another directory:

$ sh ./build.sh
$ su
# mv output/jboss-3.2.3 /opt
# exit
$ export JBOSS_HOME=/opt/jboss-3.2.3

Remove Unused Web Applications

By default, JBoss includes a lot of web applications that I personally don’t use. It is a good idea to remove them because every time starting JBoss will load these applications up by default, along with your own applications. I use the default configuration so I will modify the contents in that directory.

Code:

# cd $JBOSS_HOME/server/default/deploy
# rm -rf jmx-console.war snmp-adaptor.sar management

Remove JMS

Note that if you use any message driven beans or any JMS resources in your applications, you can’t remove JMS. For me, I don’t use JMS so taking it out works for me.

Code:

# cd $JBOSS_HOME/server/default/deploy
# rm -rf jms

Configure the Tomcat Coyote Settings

Since JBoss version 3.2.3, Tomcat is the default web container. By default, the Coyote connector listens on ports 8080 for HTTP requests and 8009 for AJP requests. This means if you plan to run the web listener with JBoss, you need to start the Coyote connector on 8080. If you have a frontend web listener (for example, Apache) which forwards HTTP requests to your JBoss instance, you need to have the Coyote connector listening on 8009 so that mod_jk/mod_jk2 in your Apache instance can talk to the Coyote connector on your JBoss. For most practical purposes, you need the Coyote listener to listen on either one of these ports.

Modify jboss-service.xml to achieve this:

# cd $JBOSS_HOME/server/default/deploy/jbossweb-tomcat41.sar/META-INF
# vi jboss-service.xml

Comment out the port you don’t want the Coyote connector to listen to. In my case I use Apache as the frontend web listener and therefore I don’t need the HTTP/1.1 connector on port 8080.

Code:

     address=”${jboss.bind.address}” port=”8009″ minProcessors=”5″ maxProcessors=”75″ enableLookups=”true” redirectPort=”8443″ acceptCount=”10″ debug=”0″ connectionTimeout=”20000″ useURIValidationHack=”false” protocolHandlerClassName=”org.apache.jk.server.JkCoyoteHandler”/>

Turn Off HTTP Access Logging

If you run a frontend Apache web listener, it already puts the web access logs in its designated log directories. Therefore there is no need for JBoss to log the web accesses again.

Code:

# cd $JBOSS_HOME/server/default/deploy/jbossweb-tomcat41.sar/META-INF
# vi jboss-service.xml

  false

Lower Your JSP Log Verbosity

If you use JSP’s, by default the log verbosity is set to WARNING. In production systems, you can adjust the verbosity to only fatal errors so that Tomcat will not log excessive error messages.

Code:

# cd $JBOSS_HOME/server/default/deploy/jbossweb-tomcat41.sar
# vi web.xml

jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
FATAL

3

Turn off Debug Information in JSP Classes

By default the Jasper JSP compiler compiles the JSP classes in debug mode. Turn it off in production systems.

Code:

# cd $JBOSS_HOME/server/default/deploy/jbossweb-tomcat41.sar
# vi web.xml

jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
FATAL

classdebuginfo
false

3

Turn off Development Mode in the Jasper Compiler

By default the Jasper JSP compiler has development and reloading set to on. Turn it off in production systems.

Code:

# cd $JBOSS_HOME/server/default/deploy/jbossweb-tomcat41.sar
# vi web.xml

jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
FATAL

classdebuginfo
false

development
false

reloading
false

3

Precompile JSP’s

You can also precompile JSP’s so that when your applications start, all the JSP classes are available and JBoss won’t invoke the Jasper compiler to automatically compile the JSP’s. Depending on how complex your applications are, this is generally a good practice although the packaging of your war files will need more work. There are a number of steps involved to have all the JSP’s precompiled:

1. Invoke the Jasper JSP compiler to generate *.java for all the JSP’s
2. Compile the *.java files (with optimize=on and debug=off)
3. Add the JSP servlets in web.xml
4. Package the resulting JSP classes with other classes in *.war archives

To accomplish these steps, I use ant. The jspc ant task will generate a portion (or fragment) of web.xml that needs to be added to the /WEB-INF/web.xml in the war archive. The trick to use is to have a comment in the /WEB-INF/web.xml and use the replace ant task to replace that comment with the web.xml fragment generated by jspc. Here is the excerpt of build.xml to precompile JSP’s.

Code:

destdir="${gen-src}/jsp-temp" classpathref="project.class.path" mce_href="project.class.path"    webinc="${gen-src}/web.war/WEB-INF/web-fragment.xml">  debug="off" optimize="on" classpathref="project.class.path" mce_href="project.class.path"   >  srcfile="${gen-src}/web.war/WEB-INF/web-fragment.xml"/>  value="${jspc.web.fragment}"/>  destfile="${build}/myapp.war" excludes="**/*.java"/>

Increase the JDBC Prepared Statements Cache

In your datasource configuration, you can increase the number of prepared statements per JDBC connection in the cache. To do that, add the following element in your ?-ds.xml in $JBOSS_HOME/server/conf/deploy.

Code:

# vi $JBOSS_HOME/server/default/deploy/postgres-ds.xml

PostgresDS
jdbc:postgresql://localhost:5432/myapp
org.postgresql.Driver
firedragon
welcome1
50

Increase the Maximum Size of the Memory Allocation Pool

If you use the Sun JVM, the default memory allocation pool size is 64Mb. Usually this is not enough for reasonably-sized enterprise web applications. To keep those dreaded OutOfMemoryError exceptions out, start the JVM with a higher value than 64Mb. The limit for the Sun JVM on the x86 platform is 2000Mb. In JBoss, you can modify $JBOSS_HOME/bin/run.conf.

Code:

# vi $JBOSS_HOME/bin/run.conf

JAVA_OPTS="-Xmx1024m"

Adjust the CMP Entity Beans Commit Options

I use both CMP and BMP entity beans. In JBoss, there are 4 commit options available for CMP entity beans:

1. Commit-option A, this bean is cached and is available between transactions. Normally this assumes that any database access is done through the container.
2. Commit-option B, this is JBoss’ default and is also known as pessimistic locking. The bean is locked in a transaction until the transaction commits or rolls back. This is true for read-only transactions as well.
3. Commit-option C, the bean passivates at the end of a transaction and is locked during a transaction.
4. Commit-option D, a background thread periodically executes ejbLoad() on beans in the cache and this option is the same as commit-option A otherwise.

In my case, database access is done through the container only. Therefore I am going to choose commit-option A. This can be done either by modifying $JBOSS_HOME/server/conf/conf/standardjboss.xml or jboss.xml in your ejb jar. The difference is by changing standardjboss.xml, the configuration will apply to all CMP entity beans whereas in jboss.xml, you can apply this new configuration on a per entity bean basis.

Code:

# vi $JBOSS_HOME/server/default/conf/standardjboss.xml

...
A

Declare Read-Only in EJB’s

JBoss will not enroll EJB’s in transactions if they are declared as read-only. If there are read-only EJB’s in your applications, it is a good idea to declare them in jboss.xml as read-only. Read-only methods can be declared as well.

Code:

$ vi jboss.xml

...

CargoEJB
true
...

Specify the Read Ahead Strategy

If you have lots of complex M:N relationships between different beans, sometimes it may be beneficial to do some prefetching of the bean fields. If you have finder methods defined for your CMP entity beans, try using on-find as your read-ahead strategy. Experiment this option with your applications.

Code:

$ vi jbosscmp-jdbc.xml

on-find
255
*

Choose a Decent JVM

I have found that the BEA JRockit performs the best out of other major JVM’s on the Linux platform when using it in combination with JBoss. You should also experiment with different JVM’s in your environment and see which one performs the best.

Final Thoughts

I wish there is more decent documentation on JBoss in the market and I am willing to pay for it. On occassions, it is fun to poke around the JBoss source code. However under tight development schedules, being able to pick up the documentation and read about the facts, tricks and solutions on JBoss is a life saver. I hope this will change in the future when JBoss decides to allocate some of its new US$10M venture capital funding for documentation.

References

1. Bill Burke’s weblog
2. JBoss Optimizations 101
3. JBoss Administration and Development, 2nd Edition, Scott Stark et al